From forrerj@ucs.orst.edu Sun Jun 02 23:12:01 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAA02444 for <HFSIG@TAPR.ORG>; Sun, 2 Jun 1996 
23:11:58 -0500 (CDT) 
Received: from p04.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AAQ5223; Sun, 2 Jun 1996 21:11:47 -0700 
Message-Id: <1.5.4.16.19960603053332.29172514@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 02 Jun 1996 21:33:32 -0800 
To: HFSIG@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: QPSK BANDWIDTH ? 


Hi all, 


Could anyone please comment on the expected bandwidth for a DQPSK signal at 
T bauds (or 2*T bits/sec) with raised cosine pulse shaping. 


I have been monitoring my QPSK signal using an FFT analyser program. My 
modulator uses a root raised cosine response with x/sinx compensation with 
alpha rolloff factor 0.2. While the QPSK signal is cycling though all its 
possible bit patterns, I observe five peaks in the emitted spectrum as follows: 


carrier at © cB, 
+/- half T at -6 dB, 
+- T at -14 dB. 


Everything else is way down in the noise. From this observation, it appears 
that the signal is contained into T Herz. Is this what is supposed to be 
there? I am a little puzzled by the two components at +/- half T, also not 
too clear whether I should or not use the x/sinx compensation in this case 
and whether the rolloff factor is suitable. Theoretically, it looks OK on 
simulations - The signal sounds nice and clean and melodic, but I may be 
missing something. 


Any comments and suggestions will be appreciated. 


--Johan 


From BRYD@KIDD.CO.ZA Mon Jun 03 01:18:30 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA13457 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
01:18:23 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 

(Smail3.1.29.1 #3) id mOuQSxs-QOOP4BC; Mon, 3 Jun 96 08:18 GMT+0200 


Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Mon, 03 Jun 1996 08:21:26 +0200 
Message-Id: <s1b2a086.016@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Mon, 03 Jun 1996 20:16:15 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: [HFSIG:1165] QPSK BANDWIDTH ? -Reply 


Hi All. 


I have made some pic's (jpg format) of my EVM interface. Interesting 
persons can email me for copies otherwise I will ask Johan to upload it to 
the web page for hf signal processing 


73 danie 
BRYD@KIDD.CO.ZA 


From mcdermot@rdxsunhost.aud.alcatel.com Mon Jun 03 08:17:54 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA24931 for <hfsig@tapr.org>; Mon, 3 Jun 
1996 08:17:51 -0500 (CDT) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 
id AA19420; Mon, 3 Jun 96 08:17:48 CDT 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 
id AA21315; Mon, 3 Jun 96 08:17:48 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ2940; Mon, 3 Jun 96 08:17:47 CDT 
Date: Mon, 3 Jun 96 08:17:47 CDT 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9606031317.AA02940@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1165] QPSK BANDWIDTH ? 


Hi all, 


Could anyone please comment on the expected bandwidth for a DQPSK signal at 
T bauds (or 2*T bits/sec) with raised cosine pulse shaping. 


I have been monitoring my QPSK signal using an FFT analyser program. My 
modulator uses a root raised cosine response with x/sinx compensation with 
alpha rolloff factor 0.2. While the QPSK signal is cycling though all its 
possible bit patterns, I observe five peaks in the emitted spectrum as follows: 


carrier at O cB, 
+/- half T at -6 dB, 
+- T at -14 dB. 


Everything else is way down in the noise. From this observation, it appears 
that the signal is contained into T Herz. Is this what is supposed to be 


VV VV VV VV VV VV VV VV 


there? I am a little puzzled by the two components at +/- half T, also not 
too clear whether I should or not use the x/sinx compensation in this case 
and whether the rolloff factor is suitable. Theoretically, it looks OK on 
simulations - The signal sounds nice and clean and melodic, but I may be 
missing something. 


Any comments and suggestions will be appreciated. 


--Johan 


VVVV VV VV VV 


Johan: it is important that all measurements be done on a linear 
channel -- ie: a class-C amplifier will significantly modify the spectrum 
of a DOQPSK signal. A staggered-offset-QPSK (OQPSK, or SQPSK) signal will not 
be widened as badly as straight QPSK, but both will widen when limited or 
clipped. 


Secondly, it is important that a PRBS (of sufficient length) 
be used to excite the filter, else you may get individual spectral lines 
showing through. If you have a repetitive pattern, the energy at the 
discrete spectral lines may confuse things. If your FFT is of short length, 
and thus it truncates the PRBS pattern, this may also lead to measurement 
error. Additionally, windowing of the FFT, and compensation of amplitude 
induced errors of the window may prove useful. 


I beleive that x/sinx compensation is correct if you are filtering 
square-wavish pulses. If you are filtering impulses, then compensation 
is of course not necessary. 


You should have -3 dB at the +/- half T points of the TX output 
spectrum regardless of the alpha factor, for a root-cosine transfer function 
that has been properly compensated. It then falls off faster past +/- 1/2T. 
At +/- T there should be no output (filtered or not). However, it is common 
to have spectral leakage at +/- 1/T due to feedthrough of the baud clock, 
and some effort may be needed to track this down. An alpha factor of 0.2 
leads to some pretty wild ringing, and it's important to assure the 
dynamic range of everything is preserved. Also, a sufficient number of filter 
taps is needed to have good out-of-band rejection at an alpha factor of 0.2, 
I think about 33 taps were needed for my prototype in Excel to have adequate 
out of band rejection. 


It sounds as though you are making excellent progress, and am glad 
to see you using root-cosine filters so that the emitted spectrum will be 
narrow. The root-cosine filter on receive will help assure good noise 
bandwidth of the receiver. Incidentally, the noise bandwidth of a 
root-cosine filter is independent of the alpha factor. 


- Tom, N5EG 


Tom McDermott | "All opinions expressed 


Alcatel Network Systems, Inc. | are my own, and do not 

mcdermot@aud.alcatel.com | represent those of Alcatel 
[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 
[ June 23-27, 1996, Dallas, Tx. ] | 


ee Si 


From BRYD@KIDD.CO.ZA Mon Jun 03 08:29:20 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id IAA25439 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
08:28:59 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuQZgm-O0OP5cC; Mon, 3 Jun 96 15:28 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell _ GroupWise; Mon, 03 Jun 1996 15:32:13 +0200 
Message-Id: <s1b3057d.004@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Tue, 04 Jun 1996 03:27:36 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Center freq for rtty ? 


By the way... 


Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz 
space) My hf rig shows much better response at 800 to 1000Hz. Would 
it not be better to implement the channel filters for a RTTY DSP modem 
around say 800Hz ? 


I am busy with a rtty dsp modem for the evm and is now wondering 

about some of my earlier choices :-) From a DSP point of view would it 
not be better to work around 800Hz ? I have used my PK232 with great 
success in the past using my 500Hz CW filter on RITTY. 


danie zs6éawk 


From hardie@duke.usask.ca Mon Jun 03 11:36:58 1996 

Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA03637 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
11:36:52 -0500 (CDT) 

Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with 
SMTP id KAA32561 for <hfsig@tapr.org>; Mon, 3 Jun 1996 10:36:38 -0600 (CST) 
Date: Mon, 3 Jun 1996 10:36:38 -0600 (CST) 

From: Pete Hardie <hardie@duke.usask.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1168] Center freq for rtty ? 

In-Reply-To: <s1b3057d.Q004@KIDD.CO.ZA> 

Message-ID: <Pine.OSF.3.93.960603102921 .3180A-100000@duke.usask.ca> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Mon, 3 Jun 1996, Danie Brynard wrote: 
> Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz 


> space) 


Back when I did a little RTTY with my KAM, I found that it could copy RTTY 
much better if I used the LOwtones command. What this did was that instead 
of using the 2125Hz Mark with the Space shifted above that, it used the 
European "low_tones" in which the Space is 1275Hz and then the Mark is 
shifted above that. I think I also had to use the INVert command. 


So perhaps you could implement these low tones. 


73 de Pete 
ve5va.qrp@usask.ca 


From FORRERJ@frl.orst.edu Mon Jun 03 12:28:14 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAAQ6309 for <hfsig@tapr.org>; Mon, 3 Jun 
1996 12:28:10 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id KAAQ4089 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
10:27:59 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
3 Jun 96 10:28:04 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 10:27:38 PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 3 Jun 1996 10:27:36 -0800 
Subject: Re: [HFSIG:1167] Re: QPSK BANDWIDTH ? 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <58825D8058E@frl.orst.edu> 


Hi Tom, 


Thanks for the insight - I am learning a lot. Seems like I'm heading in the 
right direction. 


For those that might be wondering what this is about; I have been 
exploring some of the materials in Tom's soon-to-be-released book on 
modem design. The section on pulse shaping is particularly good and 
includes extensive examples that one can play with using an Excel 
spreadsheet. 


The pulses that need to be shaped are from the QPSK I/Q channels prior to 
modulation and they are indeed approximately square waves - I chose an alpha 
factor according to what I see being used in V32 modems - but I'll play 

with some of the other factor to see the effects. In my case the raised 
cosine filter order is 65 and the FFT program uses 4096 point FFTs that 
produces some 2 Hz resolution (I do assume that the program applies 

Windows - it's the VE2IQ program). 


Pulse shaping has introduced new problems with my clock and carrier 


acquisition algorithms, mainly because they are very much based 

on signal energy over a baud. Pulse shaping cleans the signal up to 
the extent that a lot more work is now needed to obtain and 

maintain reliable clock and carrier sync. I probably now need to adda 
scrambler to whiten the spectrum. What a lot of fun! 


--Johan 


From FORRERJ@frl.orst.edu Mon Jun 03 12:35:43 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAAQ6670 for <hfsig@tapr.org>; Mon, 3 Jun 
1996 12:35:40 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id KAA04348 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
10:35:33 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
3 Jun 96 10:35:38 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 10:35:13 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 3 Jun 1996 10:35:12 -0800 
Subject: Re: [HFSIG:1168] Center freq for rtty ? 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <58846303B36@frl.orst.edu> 


Hi Danie, 


The choice of 2125/2295 tone pair goes back a long way. It however, 
probably is not the best choice and you will find that the European standard 
specifies 1275/1445. 


I dont know of any technical reason, besides IF and IF filters that makes 
one better than the other, besides some DSP algorithms that works better 
when you have more cycles of the waveform within a signaling element. You 
saw a lot of these kinds of technical arguments in the "old days" when 
folks used cassette tapes to store computer data. 


Not sure this helps. 


--Johan 


From cbuttsch@slonet.org Mon Jun 03 14:40:02 1996 
Received: from spork.callamer.com (cbuttsch@spork.callamer.com [199.74.141.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id 0AA12364 for <hfsig@tapr.org>; Mon, 3 Jun 


1996 14:39:57 -0500 (CDT) 

Received: from localhost (cbuttsch@localhost) by spork.callamer.com (8.7.5/8.7.3) 
with SMTP id MAA17100; Mon, 3 Jun 1996 12:37:45 -0700 (PDT) 

Date: Mon, 3 Jun 1996 12:37:44 -0700 (PDT) 

From: Clifford Buttschardt <cbuttsch@slonet.org> 

X-Sender: cbuttsch@spork.callamer.com 

To: Johan Forrer <FORRERJ@frl.orst.edu> 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:1170] Re: QPSK BANDWIDTH ? 

In-Reply-To: <58825D8058E@frl.orst.edu> 

Message-ID: <Pine.SOL.3.93.960603122853 .14881C -100000@spork.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Johan and Tom. I am not sure from your message who Tom might be! In 
any case, I think that the use of 2125/2975 hertz for rtty eminated from 
the first use of AFSK on sidband radios. The idea here was to place the 
tones as high in frequency as possible to avoid any harmonics from being 
radiated. The lower tones stand a chance that components will fall in the 
passband. There also were thoughts that the Q of 88 mHy inductors were 
larger at the higher frequencies. (that's all we had to work with then!) 

Let me suggest that you check carefully with Bill DeCarle regarding 
any programs of his supposedly written for windows. It was our intent to 
keep things as simple as possible and windows is as far from that concept 
as could be imagined! Cliff Buttschardt W6HDO/K7RR 


On Mon, 3 Jun 1996, Johan Forrer wrote: 
Hi Tom, 


Thanks for the insight - I am learning a lot. Seems like I'm heading in the 
right direction. 


For those that might be wondering what this is about; I have been 
exploring some of the materials in Tom's soon-to-be-released book on 
modem design. The section on pulse shaping is particularly good and 
includes extensive examples that one can play with using an Excel 
spreadsheet. 


The pulses that need to be shaped are from the QPSK I/Q channels prior to 
modulation and they are indeed approximately square waves - I chose an alpha 
factor according to what I see being used in V32 modems - but I'll play 

with some of the other factor to see the effects. In my case the raised 
cosine filter order is 65 and the FFT program uses 4096 point FFTs that 
produces some 2 Hz resolution (I do assume that the program applies 

Windows - it's the VE2IQ program). 


Pulse shaping has introduced new problems with my clock and carrier 
acquisition algorithms, mainly because they are very much based 

on signal energy over a baud. Pulse shaping cleans the signal up to 
the extent that a lot more work is now needed to obtain and 

maintain reliable clock and carrier sync. I probably now need to add a 
scrambler to whiten the spectrum. What a lot of fun! 


VV VV VV VV VV VV VV VV VV VV VV VV WV 


--Johan 


VV VV VV MV 


From FORRERJ@frl.orst.edu Mon Jun 03 15:12:36 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAA13811 for <hfsig@tapr.org>; Mon, 3 Jun 
1996 15:12:33 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id NAAQ9281 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
13:12:30 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
3 Jun 96 13:12:35 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 3 Jun 96 13:12:30 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Mon, 3 Jun 1996 13:12:27 -0800 
Subject: Re: [HFSIG:1170] Re: QPSK BANDWIDTH ? 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <58AE5537E04@fr1l.orst.edu> 


Hi Cliff, 


Thanks for the note on the high tones - I also built those 88mH 
demodulators way back - had a lot of fun! 


About "windows" - I trust you mean windows like in Hamming or Blackman- 
Harris, not Microsoft? I use Bill's program under DOS and I suspect the 
anti-alias filter a little, otherwise, the program works reasonably well, 
just don't know whether he actually use a window, i.e., a raised cosine or 
such prior to the FFT. If not, its not a matter of life and death, just the 
spectrum is a little smeared due to Gibbs affects. That is what Tom 
McDermot, N5EG, was hinting at. He has written an excellent book on modems 
for the radio communications market, and I have had the pleasure to be a 
reviewer - the book will be out soon. 


Trust you doing OK? Hows the plans for moving coming along? 

73's 

--Johan 

From karn@qualcomm.com Mon Jun 03 22:17:48 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA03345 for <hfsig@tapr.org>; Mon, 3 Jun 1996 


22:17:44 -0500 (CDT) 
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 


UAAOQ0621; Mon, 3 Jun 1996 20:17:05 -0700 (PDT) 

Date: Mon, 3 Jun 1996 20:17:05 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040317 .UAAQ0621@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.16.19960603053332.29172514@ucs.orst.edu> (message from Johan 
Forrer on Sun, 2 Jun 1996 23:15:01 -0500 (CDT)) 

Subject: Re: [HFSIG:1165] QPSK BANDWIDTH ? 


Johan, 


Are you really testing with random data? From your description and 
from your results, it sounds like you're using repeating patterns. 


You need to use random data and average your results over a fairly 
long interval. 


Phil 


From karn@qualcomm.com Mon Jun 03 22:24:12 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA03771 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
22:24:08 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
UAAQ0633; Mon, 3 Jun 1996 20:23:33 -0700 (PDT) 

Date: Mon, 3 Jun 1996 20:23:33 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040323 .UAAQ0633@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <s1b3057d.004@KIDD.CO.ZA> (message from Danie Brynard on Mon, 3 Jun 
1996 08:30:45 -0500 (CDT)) 

Subject: Re: [HFSIG:1168] Center freq for rtty ? 


>Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz 
>space) My hf rig shows much better response at 800 to 1000Hz. Would 
>it not be better to implement the channel filters for a RTTY DSP modem 
>around say 800Hz ? 


I suppose it depends on the radio. You should operate near the center 
of whatever passband you have to avoid the phase distortion that is 
invariably associated with sharp filters near cutoff. 


Phil 


From karn@qualcomm.com Mon Jun 03 22:29:07 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA03871 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
22:29:03 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
UAAQO0648; Mon, 3 Jun 1996 20:28:26 -0700 (PDT) 

Date: Mon, 3 Jun 1996 20:28:26 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040328 .UAAQ0648@servo.qualcomm. com> 


To: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
CC: hfsig@tapr.org 

In-reply-to: <9606031317 .AA02940@eagle.aud.alcatel.com> 
(mcdermot@rdxsunhost.aud.alcatel.com) 

Subject: Re: [HFSIG:1167] Re: QPSK BANDWIDTH ? 


Tom, 


Speaking of root raised cosine filters, would you be willing to design 

a few for me for use in my SQPSK modem? I have the code for your book, 
but I don't have Excel installed. I have the classic Parkes-McClellan 
FORTRAN code, but it doesn't seem to be readily adaptable to an arbitrary 
amplitude response. 


I've been rewriting my modem code to use an arbitrary length FIR 
filter. At the moment I've kept the original 8-sample boxcar shape 
that was inherent in my earlier explicit integrate-and-dump 
implementation. 


I'm using impulse signalling, so the transmit and receive filters can 
be the same. Give me a alpha of about 0.5 or so (enough to keep the 
energy at 1200 baud well within a typical SSB bandwidth). The baud rate 
is 1200, the sampling rate is 9600. Will a 33 tap filter be sufficient? 


Phil 


From karn@qualcomm.com Mon Jun 03 22:47:51 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA04761 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
22:47:48 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
UAAOQO709; Mon, 3 Jun 1996 20:47:16 -0700 (PDT) 

Date: Mon, 3 Jun 1996 20:47:16 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040347 .UAAQ0709@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <58825D8058E@frl.orst.edu> (FORRERJ@frl.orst.edu) 

Subject: Re: [HFSIG:1170] Re: QPSK BANDWIDTH ? 


Johan, 


You might consider the approach I've taken for symbol timing in my 
satellite SQPSK (aka OQPSK) modem. Rather than extract symbol timing 
from the data, I do it in a one-shot fashion at the beginning of every 
packet with a modified Barker sync sequence. Since this is a packet 
modem with a bounded packet length, I know that my one-shot estimate 
should hold as long as the crystal clocks on the two ends are 
reasonably accurate. 


For carrier recovery, I also start with a one-shot estimate taken from 
a carrier preamble, but because carrier frequency is more uncertain I 

use the preamble estimate to seed an a posteriori 4-phase Costas loop 

that updates the frequency from block to block. 


The Costas loop used to work on raw symbols, but I just changed my 
code so that once symbol timing is established, the incoming samples 
are downconverted to DC, LP filtered, rate converted and complex 
sampled at 2x the baud rate using a fixed LO downconversion frequency 
derived from the carrier burst in the preamble. 


Then the Costas loop only has to correct for the slow phase rotation 
("slow" relative to the data rate) caused by any residual error in the 
preamble frequency estimation (plus any doppler). Although complex 
samples take more operations to process, I figure I probably save 
overall from the rate conversion from 9600 samples/sec to 2400. And 
I've already LP filtered, so I don't have to do that again. 


I only need 2x sampling because of the I/Q symbol staggering; true 
QPSK would only require 1x sampling once symbol timing is established. 


Phil 


From karn@qualcomm.com Mon Jun 03 23:04:14 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id XAA06066 for <hfsig@tapr.org>; Mon, 3 Jun 1996 
23:04:11 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
VAAQ0740; Mon, 3 Jun 1996 21:03:34 -0700 (PDT) 

Date: Mon, 3 Jun 1996 21:03:34 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040403 .VAAQ0740@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <58846303B36@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:1171] Re: Center freq for rtty ? 


>I dont know of any technical reason, besides IF and IF filters that makes 
>one better than the other, besides some DSP algorithms that works better 
>when you have more cycles of the waveform within a signaling element. You 


I've given this some thought recently, since I noticed some 
interesting artifacts in my SQPSK modem receive constellation. It's 
actually inherent in modulating a low frequency carrier with boxcar 
pulses. 


I had chosen a carrier frequency of 1600 Hz and a baud rate of 1200, 
so there isn't an integral number of carrier cycles per symbol. So 
when I did a boxcar integrate-and-dump, the I and Q channels aren't 
perfectly orthogonal even when you have the carrier phase right. I 
believe this was contributing to about a 1dB implementation loss in my 
modem. 


In the frequency domain, this effect shows up as the lower spectral 
sidelobes (for unfiltered BPSK) "wrapping around" DC and aliasing back 
up into the signal spectrum. 


I verified my suspicions by testing at a carrier frequency of 2400 Hz, 
exactly 2x the baud rate. It got rid of these spectral artifacts by 
overlaying them in "safe" locations (or in the time domain, it ensured 
an integral number of carrier cycles per symbol integration time.) 


But this is not a practical solution for two reasons. First, you can't 
guarantee that the receiver will get an incoming carrier at exactly 
2400 bps, and secondly most SSB radios won't work that high anyway 
(the first null above the carrier would occur at 3600 Hz, well outside 
most SSB filters). I chose 1600 Hz in the first place precisely to 
center the signal spectrum in a typical SSB filter bandwidth. 


So I've been rewriting my modem code to include FIR filters in the I 
and Q channels in both the transmit and receive data paths. With the 
appropriate filter response, the sidelobes should be low enough to 
prevent spectral wraparound and aliasing. Or in the time domain, the 
filter impulse should be small enough at the beginning and end of the 
symbol time (where the carrier phase transition takes place) to 
minimize the effect of the fractional carrier cycle in the sampled 
filter output. 


Of course, another fix would be even "Sweeter" -- using two product 
detectors in quadrature in the receiver and feeding complex audio 
samples to the modem. This would allow the modem to distinguish easily 
between positive and negative frequency components. Unfortunately, 
most SSB transceivers don't have quadrature audio outputs... 


Phil 


From silbaugh@apci.net Mon Jun 03 23:27:33 1996 

Received: from hilly.apci.net (root@hilly.apci.net [206.100.36.3]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAAQ6886 for <HFSIG@tapr.org>; Mon, 3 Jun 1996 
23:27:30 -0500 (CDT) 

Received: from dialup178.apci.net (dialup178.apci.net [206.100.36.178]) by 
hilly.apci.net (8.6.12/8.6.9) with SMTP id XAA22147; Mon, 3 Jun 1996 23:28:13 
-0500 

Date: Mon, 3 Jun 1996 23:28:13 -0500 

Message-Id: <199606040428.XAA22147@hilly.apci.net> 

X-Sender: silbaugh@apci.net 

X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: Johan Forrer <forrerj@ucs.orst.edu> 

From: "Eric E. Silbaugh" <silbaugh@apci.net> 

Subject: Re: QPSK BANDWIDTH ? 

Cc: HFSIG@tapr.org 


Johan, 


First let's ignore the differential encoding and raised 
cosine filetering. Straight QPSK at T bauds/sec should 


have the classic sin(x)/x squared power spectrum with a 
main lobe width (null-to-null) of T Hz. What you 
consider the ‘occupied' bandwidth of this signal depends 
on your definition; for now let's use the null-to-null 
bandwidth. 


Now add raised cosine filtering. The frequency response 
of the RC filter (or composite of the RX and TX sqrt RC 
filters) will multiply the power spectrum of the original 
QPSK waveform to provide the resulting power spectrum. 
With a @.2 rolloff, the ideal raised cosine spectrum will 
have a bandwidth of 1.2T Hz. The percent excess bandwidth 
is equal to the rolloff factor. 


In the real world your filter can only approximate the 
ideal RC impulse response. Thus, the spectrum may not 
be identically zero beyond 0.6T Hz away from the carrier 
frequency. If your filter is a good approximation there 
should be little ‘splatter’ beyond 0.6T Hz. 


The previous discussion assumed the data symbols were 
uncorrelated. Differential encoding adds some memory; 
which means your symbols may not be uncorrelated anymore. 
The power spectrum of a digitally modulated signal 
depends on the autocorrelation of the data. (see 

J. G. Proakis, M. Salehi ‘Communication Systems 
Engineering,' p.537, Prentice-Hall, 1994) I think the 
effects of differential encoding on the spectrum should 
be minimal. It certainly should not change the major 
features of the spectrum. 


Sin(x)/x compensation effects should also be minimal, 
as long as your sampling rate is well above the 
Nyquist rate. Again, compensation should not change 
the major features of the spectrum. 


All this is a very long way of saying a bandwidth of 
about 1.2T Hz (almost T Hz) should be expected for 
your RC filtered DQPSK signal of T baud/sec. 


I cannot explain the discrete components you noted. 
How do you create the signal you feed into the FFT? 
How many baud periods do you use in the FFT'd signal? 
You will not get a good estimate of the average 

power spectrum from signals only a few baud long. 


To estimate the power spectrum with more detail I would 
create a signal from several tens or hundreds of random 
bits (independent) and FFT this long signal. Yes this 
will require a long FFT, but it's just like turning down 
the resolution bandwidth of a spectrum analyzer. The 
spectral resolution of the FFT is inversely proportional 
to the time duration of the signal you transform (longer 


times mean finer resolution). 


To estimate the average power spectrum you will probably 
want to use the same signal and compute the periodogram. 
Just average the FFTs of shorter segments of the signal. 
The FFT segments can overlap, but should probably be an 

integer number of bauds in length. You will be trading 

off resolution for averaging. See any good DSP book for 
details. 


No clue as to the suitability of your choosen rolloff 
factor. If it works I guess it's good enough! A factor 
of 0.2 seems to be a reasonable compromize from a 
bandwidth standpoint. How much amplitude fluctuation 

in the time-domain does the filtering add? 


Hope this helps, sorry for the bandwidth! 


Eric, N2NNP 


From forrerj@ucs.orst.edu Tue Jun 04 01:09:51 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA17355 for <HFSIG@TAPR.ORG>; Tue, 4 Jun 1996 
01:09:10 -0500 (CDT) 
Received: from p08.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA13543; Mon, 3 Jun 1996 23:08:10 -0700 
Message-Id: <1.5.4.16.19960604073016.317f6a88@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Mon, 03 Jun 1996 23:30:16 -0800 
To: HFSIG@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Root raised cosine pulse shaping. 


Hi Tom, 


Well ... After fixing a killer bug, the root raised cosine pulse shaping now 
works like it is supposed to. The nicest, tightest constellation points that 
I have seen thus far and no problem with clock or carrier extraction either. 
Very nice eye patterns - I still have to implement pulse shaping filters in 

the receiver to gain all the good benefits due to bandwidth reduction. I am 

getting excellent results with a rolloff factor of 0.6. 


Thanks for all the good hints. 
--Johan 


From BRYD@KIDD.CO.ZA Tue Jun 04 01:12:50 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 


(8.7.5/8.7.3/1.9) with SMTP id BAA17391 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
01:12:47 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuQpMC-OOOP9BC; Tue, 4 Jun 96 08:12 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Tue, 04 Jun 1996 08:16:00 +0200 
Message-Id: <sib3f0c0.001@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Tue, 04 Jun 1996 20:08:03 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: [HFSIG:1171] Re: Center freq for rtty ? -Reply 


... besides some DSP algorithms that works better when you have more 
cycles of the waveform within a signaling element..... 


I see. Well I will try to implement both and see if there are any practical 
differences. I noted that Dave W3HCF is also using the high tones in his 
DSP-93 implementation. Dave any comments from your side ? 


73 Danie zs6éawk 


From karn@qualcomm.com Tue Jun 04 01:33:29 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id BAA18009 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
01:33:26 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
XAAQ1122; Mon, 3 Jun 1996 23:32:54 -0700 (PDT) 

Date: Mon, 3 Jun 1996 23:32:54 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606040632.XAA0Q1122@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199606040428.XAA22147@hilly.apci.net> (silbaugh@apci.net) 
Subject: Re: [HFSIG:1179] Re: QPSK BANDWIDTH ? 


Eric, 
An excellent writeup. One nit: 


>cosine filetering. Straight QPSK at T bauds/sec should 
>have the classic sin(x)/x squared power spectrum with a 
>main lobe width (null-to-null) of T Hz. What you 


Shouldn't that be 2T Hz from null to null? E.g., a 1200 baud (2400 
bps) QPSK signal with carrier at 1600 Hz would have first nulls at 400 
Hz and 2800 Hz. 


Those damn factors of 2 are so easy to get wrong, especially when some 
of the textbooks talk about bits per sec and others talk about baud (2 
bits/sym for QPSK)... 


Phil 


From JSANFORD@INFI.NET Tue Jun 04 06:02:05 1996 

Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id GAA24677 for <hfsig@tapr.org>; Tue, 4 Jun 1996 

06:02:03 -0500 (CDT) 

Received: from paldsp21.orf.infi.net by mhO04.infi.net with SMTP 
(Infinet-S-3.3) id HAA13762; Tue, 4 Jun 1996 07:01:28 -0400 (EDT) 

Message-Id: <199606041101.HAA13762@mh004.inf£1i.net> 

X-Sender: jsanford@infi.net 

X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 04 Jun 1996 07:02:15 -0400 

To: hfsig@tapr.org 

From: Jim Sanford <JSANFORD@INFI.NET> 

Subject: Re: [HFSIG:1182] Re: QPSK BANDWIDTH ? 


Phil: 
Have enjoyed following all the threads you're into . 


A couple of points: 

1. For what platform are you doing the OQPSK 
satellite modem? I have 2 dsp-12's and would love to 
beta test . 

2. You made a comment about quadrature outputs 
from SSB receivers being nice but not available. I believe 
they will be, SOON. I'm working on a design using 
Analog Devices DDS's, Mini circuits DBM's, and Maxim's 
quadrature modulators/demodulators. This thing will initally 
be for HF, but easily mixed/redesigned for vhf/uhf. 

The plummeting cost of the silicon is making this cheaper 
by the day. 


Intend to initally send I and Q to a "stereo" sound card for 
easy playing with the DSP, but baseband bandwidth on the 
Maxim demods is large enough that the design will not be 
limited to audio. Will gladly share details with you, when 
the prototype is done. Believe cost will be $100 or so for 
the whole works. 


This business is getting terribly exciting -- believe we are on 
the threshold of some great capabilities at significantly lower 
prices than Icom, et al, would have us believe. Thanks for all 
you've done for the state-of-the-art. 


73, Jim 
wb4gcs@amsat.org 


> 

>Those damn factors of 2 are so easy to get wrong, especially when some 
>of the textbooks talk about bits per sec and others talk about baud (2 
>bits/sym for QPSK)... 


From ssykes@ns2.emirates.net.ae Tue Jun 04 07:36:14 1996 
Received: from ns2.emirates.net.ae (ns2.emirates.net.ae [194.170.1.7]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id HAA27539 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
07:36:07 -0500 (CDT) 
Received: from csb059.emirates.net.ae by ns2.emirates.net.ae (5.x/SMI- 
SVR495081401) 
id AA22662; Tue, 4 Jun 1996 16:35:50 +0400 
Received: by csb059.emirates.net.ae with Microsoft Mail 
id <01BB5233.827F2140@csb059.emirates.net.ae>; Tue, 4 Jun 1996 16:33:06 +-400 
Message-Id: <01BB5233.827F2140@csb059.emirates.net.ae> 
From: Stephan Sykes <ssykes@ns2.emirates.net.ae> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:1168] Center freq for rtty ? 
Date: Tue, 4 Jun 1996 16:25:54 +-400 
Encoding: 29 TEXT, 59 UUENCODE 
X-Ms-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 


I was told that the reason for the high tones was to place the harmonics of 
the tone outside of the IF filter bandwidth. Improved filters and DSP make 


this unnecessary now. 


Steve Sykes 


KD20M/A61AA 
From: Danie Brynard[SMTP: BRYD@kidd.co.za] 
Sent: Monday, June 03, 1996 12:30 PM 


To: hfsig@tapr.org 
Subject: [HFSIG:1168] Center freq for rtty ? 


By the way... 


Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz 
space) My hf rig shows much better response at 800 to 1000Hz. Would 
it not be better to implement the channel filters for a RTTY DSP modem 
around say 800QHz ? 


I am busy with a rtty dsp modem for the evm and is now wondering 

about some of my earlier choices :-) From a DSP point of view would it 
not be better to work around 800Hz ? I have used my PK232 with great 
success in the past using my 500Hz CW filter on RITTY. 


danie zs6awk 


begin 600 WINMAIL.DAT 
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From LANIER.R.A-@smtpgty.bwi.wec.com Tue Jun 04 08:44:53 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id IAA29742 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
08:44:41 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA19449; Tue, 4 Jun 1996 09:42:44 -0400 
Received: from ccMail by smtpgty.bwi.wec.com 
(IMA Internet Exchange 2.0 Enterprise) id 1B43D890; Tue, 4 Jun 96 09:43:37 -0400 
Mime-Version: 1.0 
Date: Tue, 4 Jun 1996 09:43:15 -0400 
Message-Id: <1B43D890.1858@smtpgty .bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1156] Re: DSP for Linux (was: Modem audio sample) 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


Johan, 


I would interested in the URLs you are speaking about. Also, what is 
the "size" of the box you are refering to? 


Tony, KE4ATO 


Pe) rte ee ery Ee es hee Reply Separator 
Subject: [HFSIG:1156] Re: DSP for Linux (was: Modem audio sample) 
Author: hfsig@tapr.org at BALT.SMTP 

Date: 5/23/96 9:02 PM 


Hi Steve, 


Another gem for Linux is Matcom; its a Matlab to C++ translator. Then there 
is Octave, which is a Matlab look-alike. Of course this software will only 
mean something to you if you are familiar with Matlab. Matlab allows for 
pretty sophisticated DSP evaluation and simulation. Also don't forget about 
Ptolemy - really nice but you need a fairly big Linux box to use it. 


I don't have the URL's available at the moment, but can let you know if 
there is interest. 


--Johan 


At 01:55 PM 5/23/96 -0500, you wrote: 
>At 07:22 AM 5/23/96 -0500, you wrote: 


>> Steve, 

>> 

>> Where do you find this great stuff??? 
> 


>The best way to keep up with what's new with Linux is to read the 
>comp.os.linux.announce newsgroup. There's also a web site that archives 
>them, the URL is http://www.cs.helsinki. f£i/%7Ewirzeniu/linux/cola.html. 
> 

>Otherwise, I don't watch a lot of TV. I'd much rather read and experiment :-). 
> 

>73, 

> 

> - Steve, N7HPR 

> 

>srbible@gnatnet.net 

>n7hpr@amsat.org 

>n7hpr@tapr.org 

> 

> 


From FORRERJ@frl.orst.edu Tue Jun 04 10:36:46 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAAQ5172 for <hfsig@tapr.org>; Tue, 4 Jun 
1996 10:36:44 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id IAA29269 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
08:36:41 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
4 Jun 96 08:36:46 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 4 Jun 96 08:36:35 PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Tue, 4 Jun 1996 08:36:30 -0800 
Subject: Re: [HFSIG:1177] Re: QPSK BANDWIDTH ? 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <59E4CAB540F@frl.orst.edu> 


Tom, Phil and Eric, 

Much thanks for the excellent ideas and feedback. 

I do suspect that some of the spectral lines I'm seeing with my QPSK 
signal is due to the nature of the cyclic patters that is being sent. I'll 


work on a PRBS generator as suggested. 


Clock and carrier extraction is a fascinating subject and I'll certainly 


look at Phil's ideas. For this HF modem, the symbol rate is so low that 
FFT's and all sort of things alike may be put to good use, and 

I'll get to that shortly. The main thing though is that HF is not too 
friendly to true synchronous detection methods - the key to success is to go 
for robustness in algorithm design. I think I have some ideas based on 
robustness (in the statistical sense) that seem work reasonably well, 

but need to be put through the wringer. 


I have been looking at epoch synch methods but was seeing enough drift even 
with two similar sound cards over a few seconds of signal. However, over a 
frame duration of a second or two, I suspect epoch sync may just work out 
fine. 


Keep up the good work. 


--Johan 


From forrerj@ucs.orst.edu Tue Jun 04 10:50:48 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ5759 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
10:50:44 -0500 (CDT) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AAQ2943; Tue, 4 Jun 1996 08:50:37 -0700 
Date: Tue, 4 Jun 1996 08:50:37 -0700 (PDT) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1183] Re: QPSK BANDWIDTH ? 
In-Reply-To: <199606041101.HAA13762@mh004.infi.net> 
Message-Id: <Pine.OSF.3.91.960604084018 .15342A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Jim, 
Sounds interesting. Would you care to elaborate more? 


I am sort of midway in a project building a VHF/UHF digital receiver for 
satellite work. It uses a CATV tuner for the RF front-end which has a 45MHz 
IF, 20 MHz A/D fed into a Harris DDC that feeds I/Q outputs into a stereo 
CODEC connected to a EZ-kit (ADSP-2181). I use an AD7008 DSS and a PLL for 
frequency control. 


I thought I would stay away from HF for a while until I learn a bit more 


about the RF digital dynamic range, AGC, and it's affects. Guess there is a 
lot to learn. 


On Tue, 4 Jun 1996, Jim Sanford wrote: 


Phil: 
Have enjoyed following all the threads you're into . 


A couple of points: 

1. For what platform are you doing the OQPSK 
satellite modem? I have 2 dsp-12's and would love to 
beta test . 

2. You made a comment about quadrature outputs 
from SSB receivers being nice but not available. I believe 
they will be, SOON. I'm working on a design using 
Analog Devices DDS's, Mini circuits DBM's, and Maxim's 
quadrature modulators/demodulators. This thing will initally 
be for HF, but easily mixed/redesigned for vhf/uhf. 

The plummeting cost of the silicon is making this cheaper 
by the day. 


VV VV VV VV VV VV VV WV 


I would be interested to see what sideband rejection youre going to get. 
Don't be dissapointed if it's only about 40 dB. 


> > Intend to initally send I and Q to a "stereo" sound card for 
> easy playing with the DSP, but baseband bandwidth on the 

> Maxim demods is large enough that the design will not be 

> limited to audio. Will gladly share details with you, when 

> the prototype is done. Believe cost will be $100 or so for 

> the whole works. 
> 
> 
> 
> 


This business is getting terribly exciting -- believe we are on 
the threshold of some great capabilities at significantly lower 
prices than Icom, et al, would have us believe. Thanks for al 


--Johan, KC7WW 


From dibene@VNET.IBM.COM Tue Jun 04 10:58:13 1996 

Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by tapr.org 

(8.7.5/8.7.3/1.9) with SMTP id KAAQ5916 for <hfsig@tapr.org>; Tue, 4 Jun 1996 

10:58:07 -0500 (CDT) 

Message-Id: <199606041558.KAA05916@tapr.org> 

Received: from ROMVMNIC by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8939; 
Tue, 04 Jun 96 11:57:49 EDT 

Date: Tue, 4 Jun 96 17:55:39 EDT 

From: "Alberto di Bene (xx39-2-596.25744)" <dibene@VNET.IBM.COM> 

To: hfsig@tapr.org 

Subject: Tom's books 


> For those that might be wondering what this is about; I have been 
> exploring some of the materials in Tom's soon-to-be-released book on 


> modem design. The section on pulse shaping is particularly good and 


Now you got me curious... any chance to have the title and ISBN of that 
book ? Thanks. 


73 de 


Alberto di Bene, I2PHD 


From cbuttsch@slonet.org Tue Jun 04 12:37:32 1996 

Received: from spork.callamer.com (cbuttsch@spork.callamer.com [199.74.141.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA09926 for <hfsig@tapr.org>; Tue, 4 Jun 
1996 12:36:56 -0500 (CDT) 

Received: from localhost (cbuttsch@localhost) by spork.callamer.com (8.7.5/8.7.3) 
with SMTP id KAA22180; Tue, 4 Jun 1996 10:33:44 -0700 (PDT) 

Date: Tue, 4 Jun 1996 10:33:42 -0700 (PDT) 

From: Clifford Buttschardt <cbuttsch@slonet.org> 

X-Sender: cbuttsch@spork.callamer.com 

To: Stephan Sykes <ssykes@ns2.emirates.net.ae> 

cc: Bill DeCarle <bill@ietc.ca>, hfsig@tapr.org 

Subject: Re: [HFSIG:1184] RE: Center freq for rtty 

In-Reply-To: <01BB5233.827F2140@csb059.emirates.net.ae> 

Message-ID: <Pine.SOL.3.93.960604102455 .17919D-100000@spork.callamer.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


HI All. I was one of probably many that indicated that the high tones 
were used to keep harmonics down when using AFSK in SSB rig. Indeed, 
nowdays there is no reason to use such high tones and commercially, those 
higher tones are obsolete! We used such high frequencies as we simply 
duplicated telephone channel filters in which 3 KHz was the upper limit. 
Not a one of us knew enough about fileter design to change the system! 

I fully concer with the use of 800 Hz as a center frequency. All of 
Bill DeCarles work is centered there as is all my filter designs. It 
seems a good selection although a short time ago I was thumping for 500 
Hertz as it would have make synthesizer design simpler...I lost!! 

Danie- I have no way of knowing what you said in the Winmail portion 
of your note. Can't cope with that! sorry Cliff Buttschardt W6HDO/K7RR 


On Tue, 4 Jun 1996, Stephan Sykes wrote: 


> I was told that the reason for the high tones was to place the harmonics of 
> the tone outside of the IF filter bandwidth. Improved filters and DSP make 
> this unnecessary now. 

> 

> Steve Sykes 

> KD20M/A61AA 

> 

ee 

> From: Danie Brynard[SMTP:BRYD@kidd.co.za] 

> Sent: Monday, June 03, 1996 12:30 PM 

> To: hfsig@tapr.org 

> Subject: [HFSIG:1168] Center freq for rtty ? 

> 

> By the way... 

> 

> Why was such high tones selected for RTTY ? (2125Hz mark, 2295Hz 

> space) My hf rig shows much better response at 800 to 1000Hz. Would 

> it not be better to implement the channel filters for a RTTY DSP modem 

> around say 800Hz ? 


VV VVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


I am busy with a rtty dsp modem for the evm and is now wondering 

about some of my earlier choices :-) From a DSP point of view would it 
not be better to work around 800Hz ? I have used my PK232 with great 
success in the past using my 500Hz CW filter on RTTY. 


danie zs6awk 
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From karn@qualcomm.com Tue Jun 04 15:07:53 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA15704 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
15:07:50 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.8) id 
NAA10211; Tue, 4 Jun 1996 13:07:12 -0700 (PDT) 

Date: Tue, 4 Jun 1996 13:07:12 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606042007 .NAA10211@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199606041101.HAA13762@mh004.infi.net> (message from Jim Sanford on 
Tue, 4 Jun 1996 06:10:36 -0500 (CDT)) 

Subject: Re: [HFSIG:1183] Re: QPSK BANDWIDTH ? 


> 1. For what platform are you doing the OQPSK 
>satellite modem? I have 2 dsp-12's and would love to 
>beta test . 


The platform is a generic 486 or Pentium PC running my KA9Q NOS TCP/IP 
package. The modem will be integrated in as an interface driver for a 
SoundBlaster 16 card xwithout*x any special DSP chips. 


Your work with the ‘digital friendly' receiver sounds very 
interesting! I do hope that whatever you come up with can be easily 
replicated by the average amateur -- in my experience, that's where 
many promising amateur hardware projects fall down. It's the main 
reason I've become so interested in using mass-market PC hardware to 
the greatest possible extent, doing everything else in software. But 
there are definite limits to the available hardware (particularly in 
the radios) so your work is most welcome. I agree, this stuff ought 
not to be as expensive and complicated as it seems to be. 


At Dayton I looked at some of the companies selling after-market 


crystal filters for commercial SSB transceivers with an eye toward 
modifying them for wider baseband bandwidths. Ideally I'd like a ~20 
KHz bandwidth so I could fully utilize the A/D bandwidth of a PC sound 
card. I could even create a new "IF" at, say, 10 KHz and do my final 
"product detection" in DSP software. 


The guy behind the Fox-Tango table, being used to selling very sharp 
and narrow crystal filters for HF contest and DX use, couldn't figure 
out why in the world I would want to make my rig go xwiderx. Ah, the 
"narrowband mindset" seems pretty well entrenched. :-) 


Phil 


From LAITINEN@ESHOP.UOREGON.EDU Tue Jun 04 15:49:09 1996 

Received: from ESHOP.UOREGON.EDU (eshop.uoregon.edu [128.223.94.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id PAA17008 for <hfsig@tapr.org>; Tue, 4 Jun 1996 
15:49:05 -0500 (CDT) 

Date: Sun, 4 Jun 1995 13:48:40 -0700 (PDT) 

From: LAITINEN@ESHOP.UOREGON.EDU 

Message-Id: <950604134841.b9b@ESHOP .UOREGON.EDU> 

Subject: RE: [HFSIG:1189] RE: Center freq for rtty 

To: hfsig@tapr.org 

X-Vmsmail-To: SMTP%"hfsig@tapr.org" 


Gee, I thought that the use of 2125/2975 Hz for AFSK tones in the old 

days was related to running AFSK RATT on 2-meters "AM" (and then 
eventually FM). Tuning the AFSK generator and TU filters to the proper 
frequencies was done using standard tuning forks and lisajous (spelling?) 
patterns on an oscilloscope. Standard landline VFCT (Voice Freq Carrier 
Telegraph) systems (as I recall) were set up with 85-Hz channels and the 
tools (i.e., tuning forks) were around for tuning such things... Thus the 
harmonic relationships of the old 2125/2975 tones to these tuning fork 
standards were important... 


My first 2-meter RATT setup used an ARC-5/T-23 surplus aircraft radio 
modulated by an Eico 730K modulator. The RATT gear was a Model 19 with a 
W2JAV TU (the one with four neon bulbs on the front).... The receiver was 
the 417A converter that was popular in the early 1960's for Project OSCAR... 


Larry, WA6JYI/7 


From wd5ivd@tapr.org Tue Jun 04 20:49:23 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id UAA29453 for 
hfsig@tapr.org; Tue, 4 Jun 1996 20:49:22 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199606050149.UAA29453@tapr.org> 

Subject: Re: [HFSIG:1188] Tom's books 

To: hfsig@tapr.org 

Date: Tue, 4 Jun 1996 20:49:22 -0500 (CDT) 

In-Reply-To: <199606041558.KAA05916@tapr.org> from "Alberto di Bene" at Jun 4, 96 
11:10:08 am 

X-Mailer: ELM [version 2.4 PL25] 


Content-Type: text 


Title: Wireless Digital Communications: Design and Theory 
By: Tom McDermott, N5EG 
ISBN: 0-9644707-2-1 


Anticipated price will be $39.00 


With luck it will be available from TAPR the end of August/first of Sept. 
Tom is currently doing small technical corrections and the proof-reader is 
working over grammer issues. I get those elemtns and then with luck we go 
to thew e printers. 


I think there is a web page already on the tapr web server under 
publications. If it isn't there -- then I have it ready, but haven't put it 
up yet,. Has a complete index...that is if it is up. 

This has been a year and a half project. Will be glad to get it finsihed. 
Cheers - Greg, WD5IVD 

> For those that might be wondering what this is about; I have been 

> exploring some of the materials in Tom's soon-to-be-released book on 


> modem design. The section on pulse shaping is particularly good and 


Now you got me curious... any chance to have the title and ISBN of that 
book ? Thanks. 


73 de 
Alberto di Bene, I2PHD 


VV VV VV VV VV VV 


From BRYD@KIDD.CO.ZA Wed Jun 05 01:13:35 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA14915 for <hfsig@tapr.org>; Wed, 5 Jun 1996 
01:13:27 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuRBbI-OOOPEZC; Wed, 5 Jun 96 07:57 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Wed, 05 Jun 1996 08:01:08 +0200 
Message-Id: <sib53ec4.049@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Wed, 05 Jun 1996 19:56:05 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: [HFSIG:1191] RE: Center freq for rtty -Reply 


Larry now that is interesting. Thanks for the bit of history. 


danie 


From LANIER.R.A-@smtpgty.bwi.wec.com Wed Jun 05 10:56:50 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQ2516 for <hfsig@tapr.org>; Wed, 5 Jun 1996 
10:56:48 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AAQ4947; Wed, 5 Jun 1996 11:53:42 -0400 
Received: from ccMail by smtpgty.bwi.wec.com 
(IMA Internet Exchange 2.0 Enterprise) id 1B5ADB10; Wed, 5 Jun 96 11:54:25 -0400 
Mime-Version: 1.0 
Date: Wed, 5 Jun 1996 09:48:54 -0400 
Message-Id: <1B5ADB10.1858@smtpgty.bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Sine wave PROM 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I am trying to locate information on generating sine wave data for a 
EEPROM. I had an article (Radio Electronics) describing this by using 
a C program to generate the data. However, I can't find the article. 


Can someone help with this problem? 


73s de 
Tony, KE4ATO 


From silbaugh@apci.net Wed Jun 05 22:39:35 1996 

Received: from hilly.apci.net (root@hilly.apci.net [206.100.36.3]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id WAA26548 for <hfsig@tapr.org>; Wed, 5 Jun 1996 
22:39:32 -0500 (CDT) 

Received: from dialup167.apci.net (dialup167.apci.net [206.100.36.167]) by 
hilly.apci.net (8.6.12/8.6.9) with SMTP id WAAQ7740 for <hfsig@tapr.org>; Wed, 5 
Jun 1996 22:40:02 -0500 

Date: Wed, 5 Jun 1996 22:40:02 -0500 

Message-Id: <199606060340.WAAOQ7740@hilly.apci.net> 

X-Sender: silbaugh@apci.net 

X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: "Eric E. Silbaugh" <silbaugh@apci.net> 

Subject: Re: QPSK BANDWIDTH ? 


Phil, 
Good nit! Fourier is probably turning in his grave. 
I was visualizing the spectra at baseband, wrote about it as 


RF modulated, and forgot to multiply the bandwidths by two. 
Arrrggsh! Thus, the first null in a QPSK signal of T baud will 


be T Hz away from the carrier; the main lobe width is 2T Hz; 
and the bandwidth with raised cosine filtering, rolloff factor 
of 0.2, will be 2.4T Hz. 


Did I get it right this time? 
Eric, N2NNP 


From FORRERJ@frl.orst.edu Thu Jun 06 13:20:28 1996 
Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA29406 for <hfsig@tapr.org>; Thu, 6 Jun 
1996 13:20:23 -0500 (CDT) 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.118.10]) by cornus.FSL.ORST.EDU 
(8.6.9/8.6.9) with ESMTP id LAA10445 for <hfsig@tapr.org>; Thu, 6 Jun 1996 
11:20:19 -0700 
Received: from FRL/SpoolDir by frl.orst.edu (Mercury 1.21); 
6 Jun 96 11:20:22 PST8PDT 
Received: from SpoolDir by FRL (Mercury 1.21); 6 Jun 96 11:20:03 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Thu, 6 Jun 1996 11:20:01 -0800 
Subject: Further thoughts on pulse shaping for HF 
Priority: normal 
X-mailer: Pegasus Mail v3.22 
Message-ID: <5D1078A41EC@fr1l.orst.edu> 


Hi folks, 
Another thought/question on pulse shaping for HF; 


Consider the recovered signals from a QPSK modem where the final product 
is a raised cosine - I do encounter a little annoying sideffect. In the 

vacinity of the sampling point, one has to read both I and Q - for QPSK 

case, one expects that either I or Q must be near zero, i.e. a pair from 
the set {1,0 -1,0 0,1 0,-1 for I/Q}. 


Unfortunately, however, the pulse shaping procedure forces part of the pulse 
beyond the +/-T mark, to go negative, which, combined with a bit of jitter 
introduced by the channel effects, causes the channel that is supposed to 

be zero, to an off-zero value. These uncertainties are further aggravated 
that this error in the zero value, changes fairly rapidly in the vacinity of 
the sampling point. It would have been nice if things around the zero 
transition were a bit more stable. 


Now, if I were to use another shape function like Dolph-Chebychef, or 

the Blackman-Harris shape for minimum sidelobes, instead of raised cosines, 
I would not have true nyquist pulses - the tradeoff is a some of ISI, 
however, would'nt the result be more robust against this jitter problem as 
described above. I.e., would'nt the tradeoff between ML detection and 
robustness for clock/carrier extraction, which is more crucial, make 
sense? 


Comments or suggestions would be appreciated. 


--Johan, KC7WW 


From karn@qualcomm.com Thu Jun 06 20:19:35 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA14417 for <hfsig@tapr.org>; Thu, 6 Jun 1996 
20:19:32 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA15345; Thu, 6 Jun 1996 18:18:57 -0700 (PDT) 

Date: Thu, 6 Jun 1996 18:18:57 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606070118.SAA15345@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199606060340.WAAO7740@hilly.apci.net> (silbaugh@apci.net) 
Subject: Re: [HFSIG:1195] Re: QPSK BANDWIDTH ? 


>I was visualizing the spectra at baseband, wrote about it as 
>RF modulated, and forgot to multiply the bandwidths by two. 
>Arrrgggh! Thus, the first null in a QPSK signal of T baud will 
>be T Hz away from the carrier; the main lobe width is 2T Hz; 
>and the bandwidth with raised cosine filtering, rolloff factor 
>of 0.2, will be 2.4T Hz. 


>Did I get it right this time? 


Almost. The null-to-null bandwidth of 2T Hz looks right, but with 
raised cosine filtering the bandwidth will be xless* than the 
unfiltered null-to-null bandwidth. 


Phil 


From karn@qualcomm.com Thu Jun 06 20:32:11 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA14730 for <hfsig@tapr.org>; Thu, 6 Jun 1996 
20:32:09 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA15427; Thu, 6 Jun 1996 18:31:38 -0700 (PDT) 

Date: Thu, 6 Jun 1996 18:31:38 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606070131.SAA15427@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <5D1078A41EC@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:1196] Further thoughts on pulse shaping for HF 


>Consider the recovered signals from a QPSK modem where the final product 
>is a raised cosine - I do encounter a little annoying sideffect. In the 

>vacinity of the sampling point, one has to read both I and Q - for QPSK 

>case, one expects that either I or Q must be near zero, i.e. a paix from 
>the set 41,0 -1,0 0,1 0,-1 for I/Q}. 


Well, you can use any convention you like, but the usual one is to 
signal with the set { (a,a), (-a,a), (-a,-a), (a,-a) } with a=sqrt(2) 
times the signal magnitude and with the detectors looking 
independently at the I and Q components. That is, since I and Q are 
(ideally) orthogonal the I detector simply produces 1 or -1 (or a soft 
decision sample somewhere in this range) without caring what is going 
on in the Q channel. And vice versa. 


This particular constellation is used by the 4-phase costas loop, 
which will drive the I and Q components to equal amplitude. You can of 
course use the constellation you described, but then you have to 
rotate your decision regions so they're no longer aligned with the I 
and Q axes. 


Phil 


From n4hy@ccr-p.ida.org Fri Jun 07 09:58:16 1996 

Received: from idacrd.ccr-p.ida.org (idacrd.ccr-p.ida.org [198.3.41.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA16703 for <hfsig@tapr.org>; Fri, 7 Jun 
1996 09:58:09 -0500 (CDT) 

Received: from idacrd.ccr-p.ida.org (daemon@localhost) by idacrd.ccr-p.ida.org 
(8.7.2/8.7.2) with ESMTP id KAAQ3102 for <hfsig@tapr.org>; Fri, 7 Jun 1996 
10:58:23 -0400 (EDT) 

Received: from ccr-p.ida.org (xida.ccr-p.ida.org [198.3.6.62]) by idacrd.ccr- 
p.ida.org (8.7.2/8.7.2) with SMTP id KAAQ3098 for <hfsig@tapr.org>; Fri, 7 Jun 
1996 10:58:22 -0400 (EDT) 

Received: from growler.ccr-p.ida.org (growler.ccr-p.ida.org [198.3.6.3]) by ccr- 
p.ida.org (8.6.12/8.6.12) with ESMTP id KAA01840 for <hfsig@tapr.org>; Fri, 7 Jun 
1996 10:57:41 -0400 

From: Bob McGwier <n4hy@ccr-p.ida.org> 

Received: (from n4hy@localhost) by growler.ccr-p.ida.org (8.7.5/8.7.3) id KAAQ0644 
for hfsig@tapr.org; Fri, 7 Jun 1996 10:57:40 -0400 (EDT) 

Date: Fri, 7 Jun 1996 10:57:40 -0400 (EDT) 

Message-Id: <199606071457 .KAAQ00644@growler.ccr-p.ida.org> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1196] Further thoughts on pulse shaping for HF 

In-reply-to: <5D1078A41EC@frl.orst.edu> (FORRERJ@fr1.orst.edu) 


A good approximation to the ML detector for clock AND data together is what 
you need Johan. Take the final pulse shape (sampled) and its derivative 
(Guess at this or approximate it. If it is raised cosine, you may compute 
Tt): Call these signals P(i) and P'(i) , i= -n, -(n-1), ..., 0,1,2,... 
(n-1),n respectively. Suppose for this exercise that you have an approximate 
time for the CENTER (the sampling time) for the I and Q channel bauds. 


At the putative sampling time t, compute PxS(t) and P'xS(t). That is, 
convolve the pulse shape, and its derive with the baseband signal S and do 
it for S from the I and Q channel. The SIGN of the P*S is the guessed at 
symbol and SIGN(P*S(t))x*xtanh [P'*S(t)] = ERROR signal to be multiplied 

by the gain which will determine your "loop bandwidth". If you are running 
a first order loop for clock, this signal (gain*xERROR) is applied to the 
phase of your clock and then you march along to the next symbol time. This 
is MUCH more robust, stable, etc, than using clock edges, or zero crossings, 
and so long as you have the pulse shape "about right", even ISI, jitter, 
does not disturb you much. This was proposed a long time ago, before the 
advent of DSP devices by Umberto Mengali. It was proven by yours truly that 
this converges under certain conditions which are near to reality to the 
maximum likelihood estimator. 


A diagram of this might be more useful to nonmathematicians ;=): 


Soft Decision -> -> -> Decoder 


| 
| 
| Data 
| 
| | 
>->-> P*S -> -> fHard Limiter? ->-> | 
| 
| 
S(t) -> Product -> -> ERROR to clock 
| 
| 


| 
| 
| 
| 
| 
| 
->->-> P'xS -> -> -> tanh -> -> -> ->->| 

The obvious way of combining this for each channel would be to average, 

or in the case of staggered, run the clock at two times the individual symbol 
rate and alternate the channels feeding the clock. You may run this as 

a second order phase locked loop if you believe the clock frequency is also 
unstable. I used this to derive clock for a really noisy signal from 

Venus (VEGA Balloon probe). STAY AWAY FROM CLOCK EDGES in a really good 
modem. Implement the tanh with a table look up and/or some approximation 
that you find useful. The major condition is that the pulse shape in 

a idealized channel has zero's at the baud time for neighboring bauds. 

I have found it to be quite robust. I use Passband equalization whenever 
possible. The two possible outputs for data depends on whether or not there 
is error correction coding that needs soft decisions. You will pay larger 
than a 2 dB penalty to use the hard decision tap for your decoder on HF 
channels should you decide to go that way. There are other forms of this, 
but this one is one of the easiest to implement. 


Bob 


Dr. Robert W. McGwier | n4hy@ccr-p.ida.org: ham radio, scouts, 
Center for Communications Research | astronomy, golf (o yea, & math!) 


Princeton, N.J. 08520 | Cmte member Troop 5700, ACM Pack 53, 
(609) -279-6240(v) (609) -924-3061(£)| Frmr Cncl Comm. GWC 362 Sanhican #2 WwW, 
(609) -443-8963 (h) | I used to be a Buffalo . . . NE III-120 
Explorer Post 995 advisor | proud parent in Brownie Troop 196 


From forrerj@ucs.orst.edu Sat Jun 08 13:18:47 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA22005 for <hfsig@tapr.org>; Sat, 8 Jun 1996 
13:18:39 -0500 (CDT) 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA09996; Sat, 8 Jun 1996 11:18:23 -0700 
Message-Id: <1.5.4.16.19960608194055. 3f£8fec56@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 08 Jun 1996 11:40:55 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1199] Re: Further thoughts on pulse shaping for HF 


Hi Bob, 
Thanks for sharing your ideas - also welcome to HFSIG. 


At 10:00 AM 6/7/96 -0500, you wrote: 

> 

> 

>A good approximation to the ML detector for clock AND data together is what 
>you need Johan. 


I suspect you are right. The question that have been on my mind lately 
regards how much of the ideas that we commonly use for synchronous 
demodulation is worth implementing on HF. As an example, I have been playing 
with a low baudrate QPSK demodulator over the last few weeks where most of 
the clock and carrier extraction ideas are based on robust non-syncronous 
measures. I have had some encouraging results, but everything is not quite 
working either. The ideas are based roughly on the following two guidelines: 


1) Do clock extraction first because 
a) The middle of the baud is where the signal has most energy and 
there is 
best phase stability (stay away from the transition zones). 
b) Attempt carrier extraction xonlyx during this stable period. 


2) Decision-directed carrier extraction - preferably not based on PLL's or 
Costas loops. 


On the latter subject; I have played and struggled with various ideas - what 


I found was that the extended Costas loop (i.e., with I/Q sgn and summming 
of cross products) works very nicely indeed with waveforms that is not 
overly distorted. In fact in Frerking's book (Digital Signal Processing in 
Communications Systems, Marvin Frerking ISBN 0442016166 p.444) makes you 
aware of the fact that you xnot*x use the output of a matched filter but a 
lowpass filter to steer the Costas loop. I have found this to be valid. 


This is one reason why I'm quite interested in certain constellations that 
is easier to deal with than others. 


>Take the final pulse shape (sampled) and its derivative 

>(Guess at this or approximate it. If it is raised cosine, you may compute 
>it). Call these signals P(i) and P'(i) , i= -n, -(n-1), ..., 0,1,2,... 
>(n-1),n respectively. Suppose for this exercise that you have an approximate 
>time for the CENTER (the sampling time) for the I and Q channel bauds. 

> 

>At the putative sampling time t, compute PxS(t) and P'xS(t). That is, 
>convolve the pulse shape, and its derive with the baseband signal S and do 
>it for S from the I and Q channel. The SIGN of the PxS is the guessed at 
>symbol and SIGN(P*S(t))*xtanh [P'*S(t)] = ERROR signal to be multiplied 

>by the gain which will determine your "loop bandwidth". If you are running 
>a first order loop for clock, this signal (gain*xERROR) is applied to the 
>phase of your clock and then you march along to the next symbol time. This 
>is MUCH more robust, stable, etc, than using clock edges, or zero crossings, 
>and so long as you have the pulse shape "about right", even ISI, jitter, 
>does not disturb you much. This was proposed a long time ago, before the 
>advent of DSP devices by Umberto Mengali. It was proven by yours truly that 
>this converges under certain conditions which are near to reality to the 
>maximum likelihood estimator. 


Ah .. I like this idea and will give it some more thought. Could you be so 
kind and give us the full references. 


> 
>A diagram of this might be more useful to nonmathematicians ;=): 


Soft Decision -> -> -> Decoder 


| 
| 
| Data 
| 


| | 

->->-> PxS -> -> tHard Limitert ->-> | 

| | 

| | 
-> | Product -> -> ERROR to clock 
| 
| 
| 


VV VV VV VV VV 
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> ->->-> P'xS -> -> -> tanh -> -> -> ->->| 

> 

>The obvious way of combining this for each channel would be to average, 

>or in the case of staggered, run the clock at two times the individual symbol 
>rate and alternate the channels feeding the clock. You may run this as 

>a second order phase locked loop if you believe the clock frequency is also 
>unstable. I used this to derive clock for a really noisy signal from 

>Venus (VEGA Balloon probe). STAY AWAY FROM CLOCK EDGES in a really good 
>modem. 


I guess we agree that the usual synchronous demodulation ideas needs careful 
rethinking. 


>Implement the tanh with a table look up and/or some approximation 
>that you find useful. The major condition is that the pulse shape in 
>a idealized channel has zero's at the baud time for neighboring bauds. 


Would it thus be an advantage to use such a shaping function; I do know that 
the Dolph-chebycheff and Blackman-Harris shapes, for example, was designed 
for that. 


>I have found it to be quite robust. I use Passband equalization whenever 
>possible. 


How is this done? using adaptive FIR structures? does this require some kind 
of training sequence? 


>The two possible outputs for data depends on whether or not there 

>is error correction coding that needs soft decisions. You will pay larger 
>than a 2 dB penalty to use the hard decision tap for your decoder on HF 
>channels should you decide to go that way. There are other forms of this, 
>but this one is one of the easiest to implement. 

> 

>Bob 

> 

>Dr. Robert W. McGwier 

>Center for Communications Research 
>Princeton, N.J. 08520 

> (609) -279-6240(v) (609) -924-3061(£) 
> (609) -443-8963 (h) 

>Explorer Post 995 advisor 

> 


n4hy@ccr-p.ida.org: ham radio, scouts, 
astronomy, golf (o yea, & math!) 

Cmte member Troop 5700, ACM Pack 53, 

Frmxr Cncl Comm. GWC 362 Sanhican #2 WWW, 
I used to be a Buffalo . . . NE III-120 
proud parent in Brownie Troop 196 


VvVV Vv 


Pardon if I seem too inquisitive and ask too many dumb questions. 


--Johan, KC7WW 


From hardie@duke.usask.ca Sat Jun 08 14:47:08 1996 


Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id O0AA24958 for <hfsig@tapr.org>; Sat, 8 Jun 1996 
14:47:05 -0500 (CDT) 

Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with 
SMTP id NAAO9131 for <hfsig@tapr.org>; Sat, 8 Jun 1996 13:46:57 -0600 (CST) 
Date: Sat, 8 Jun 1996 13:46:57 -0600 (CST) 

From: Pete Hardie <hardie@duke.usask.ca> 

To: hfsig@tapr.org 

Subject: Stuck at the beginning 


In-Reply-To: <1.5.4.16.19960608194055. 3£8fec56@ucs.orst.edu> 
Message-ID: <Pine.OSF.3.93.960608132158 .5705A-100000@duke.usask.ca> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


I'm just starting with DSP and thought (after creating some CW FIR 
filters) that I'd try to implement a 1200 baud packet TNC on the EZ-KIT 
Lite. 

I had assumed that implementing the modulation side of this was going to 
be easy but I've run into a major hurdle that I can't figure out. 


Generating the NRZI data and modulating it as a continuous phase FSK audio 
signal was easy. I have set up the DSP program so that it reads KISS 
packets from the RS-232 port and then generates the FSK. However, if I put 
the audio from the Kit into either my KAM or Tiny-2 neither of them will 
decode a packet. I tried this with passall on so that even if the CRC were 
bad they should print something out - but they don't. In both cases their 
DCD LED does come on while the packet audio is present so they're seeing 
something. (BTW - I have used a frequency counter to check the frequency 
and stability of the generated tones and of the data bit rate and they're 
bang on). 


Next step was that I wrote two programs on my Amiga. One samples the 
parallel port (I called this program "scope") and the other (called 
"nrzi") takes the results from "Scope" and decodes it back to the original 
data bits (and if the CRC is OK it also attempts to print the AX25 
header). 


I connect the NRZI digital output of the TNC's modem (3105) into the 
parallel port and "scope" samples this at any rate I choose. 


If I play the DSP audio into the TNC and sample its modem's NRZI output, 
"nxrzi" decodes it with no problem. But, if I look at the RS-232 output of 
the TNC itself it doesn't send the content of the packet to the computer. 


The bit that really throws me is that if I connect the TNC to the audio 
from my radio and then run "scope" and "nrzi" on what the TNC hears, the 
"nxrzi" program decodes "real" packets without any trouble too and this is 
using exactly the same sampling rates as I used to sample the audio from 
the DSP. 


The fact that I can decode the NRZI output from the TNC modem eliminates 
several possible problems such as incorrect audio tones and the fact that 


the "nrzi" program can decode "real" packets using the modem's NRZI output 
suggests that the timing is also correct. 


I'm lost. I know this is "back to basics" for most of you but has anyone 
any idea where I can start looking for the problem? 


73 de Pete 
ve5va.qrp@usask.ca 


From mwestfal@csci.csusb.edu Sat Jun 08 21:19:21 1996 
Received: from silicon.csci.csusb.edu (silicon.csci.csusb.edu [139.182.38.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA09069 for <hfsig@tapr.org>; Sat, 8 Jun 
1996 21:19:18 -0500 (CDT) 
Received: by silicon.csci.csusb.edu (5.0/SMI-SVR4) 
id AA12396; Sat, 8 Jun 1996 19:33:41 +0800 
From: mwestfal@csci.csusb.edu (Michael Westfall) 
Received: by csci.csusb.edu id TAA20047; Sat, 8 Jun 1996 19:22:49 -0700 (PDT) 
(8.7.1 Berkeley Sendmail) 
Message-Id: <199606090222.TAA20047@csci.csusb.edu> 
Subject: Re: [HFSIG:1201] Stuck at the beginning 
To: hfsig@tapr.org 
Date: Sat, 8 Jun 1996 19:22:48 -0700 (PDT) 
In-Reply-To: <Pine.OSF.3.93.960608132158 .5705A-100000@duke.usask.ca> from "Pete 
Hardie" at Jun 8, 96 02:57:28 pm 
Reply-To: mwestfal@csci.csusb.edu 
X-Hi-Mom: Send more money! 
Organization: The Hackers' Guild 
X-Mailer: ELM [version 2.4 PL20] 
Content-Type: text 


I'm just starting with DSP and thought (after creating some CW FIR 
filters) that I'd try to implement a 1200 baud packet TNC on the EZ-KIT 
Lite. 

I had assumed that implementing the modulation side of this was going to 
be easy but I've run into a major hurdle that I can't figure out. 


Generating the NRZI data and modulating it as a continuous phase FSK audio 
Signal was easy. I have set up the DSP program so that it reads KISS 
packets from the RS-232 port and then generates the FSK. However, if I put 
the audio from the Kit into either my KAM or Tiny-2 neither of them will 
decode a packet. 


VV VV VV VV VV MV 


I would guess what you are forgetting is to add the HDLC frame flags and 
bit-stuffing.... 


> 
> I'm lost. I know this is "back to basics" for most of you but has anyone 
> any idea where I can start looking for the problem? 


I'm no expert, so I'll defer to someone else to explain further... 


73 de Mike, ax.25net: N6KUY@W6IBT .4#SOCA.CA.USA.NA 
amprnet: n6ékuy@n6kuy.ampr.org [44.18.0.49] 


internet : mwestfal@csci.csusb.edu 
web: http: //orion.csci.csusb.edu:8080 
"Linux: The Gates of Hell shall not prevail." 
GCS/M { -d+ p+ c++ 1 ut++ e+(%) m++(-) S/+ !n-(---) h-- !f g+ w+ t++ r-(--) yt $ 


From hardie@duke.usask.ca Sat Jun 08 22:27:03 1996 

Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA11050 for <hfsig@tapr.org>; Sat, 8 Jun 1996 
22:27:00 -0500 (CDT) 

Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with 
SMTP id VAAQ8814 for <hfsig@tapr.org>; Sat, 8 Jun 1996 21:26:57 -0600 (CST) 
Date: Sat, 8 Jun 1996 21:26:57 -0600 (CST) 

From: Pete Hardie <hardie@duke.usask.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1202] Re: Stuck at the beginning 

In-Reply-To: <199606090222.TAA20047@csci.csusb.edu> 

Message-ID: <Pine.OSF.3.93.960608212140 .22169A-100000@duke.usask.ca> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Sat, 8 Jun 1996, Michael Westfall wrote: 


> I would guess what you are forgetting is to add the HDLC frame flags and 
> bit-stuffing.... 


That's all in there Mike because: 

(a) I know they are in the DSP program. 

(b) My "nxrzi" program which decodes the signals not only decodes mine 
correctly from the DSP but it also correctly decodes real packets off the 
air. So my DSP has to be generating the flags and bit-stuffing otherwise 
the "nrzi" program wouldn't decode it. 


Thanks for the reply. 


73 de Pete 
ve5va.qrp@usask.ca 


From forrerj@ucs.orst.edu Sun Jun 09 01:00:05 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id BAA23096 for <hfsig@tapr.org>; Sun, 9 Jun 1996 
01:00:03 -0500 (CDT) 
Received: from p04.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AAQ5625; Sat, 8 Jun 1996 22:59:57 -0700 
Message-Id: <1.5.4.16.19960609072233 .38677264@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 08 Jun 1996 23:22:33 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 


Subject: Re: [HFSIG:1201] Stuck at the beginning 
Hi Pete, 


My two cent's worth: 


> 
>The fact that I can decode the NRZI output from the TNC modem eliminates 
>several possible problems such as incorrect audio tones and the fact that 
>the "nxrzi" program can decode "real" packets using the modem's NRZI output 
>suggests that the timing is also correct. 

> 


Seems like "nrzi" can decode both packets taken from your TNC's modem and 
your DSP signal source - so that looks like the format is OK. 


Have you looked at the audio levels going to the real TNC when you try your 
DSP signal source? Perhaps they are overdriving the TNC. TNC's are quite 
sensitive to the level and the fact that you see DCD comes on may not mean 
too much. Perhaps some form of level adjustment may help. Otherwise, I would 
defininately listen to that audio with an amplified speaker or scope and 
determine whether is clean and without hum. 


>I'm lost. I know this is "back to basics" for most of you but has anyone 
>any idea where I can start looking for the problem? 

> 

>73 de Pete 

>ve5va.qrp@usask.ca 

> 

> 


Looks like you are well on your way. 
--Johan 


From hardie@duke.usask.ca Sun Jun 09 20:29:18 1996 

Received: from duke.usask.ca (duke.usask.ca [128.233.3.13]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA00317 for <hfsig@tapr.org>; Sun, 9 Jun 1996 
20:25:26 -0500 (CDT) 

Received: from localhost (hardie@localhost) by duke.usask.ca (8.7.3/8.7.3) with 
SMTP id TAA30004 for <hfsig@tapr.org>; Sun, 9 Jun 1996 19:23:56 -0600 (CST) 
Date: Sun, 9 Jun 1996 19:23:56 -0600 (CST) 

From: Pete Hardie <hardie@duke.usask.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1204] Re: Stuck at the beginning 

In-Reply-To: <1.5.4.16.19960609072233 .38677264@ucs.orst.edu> 

Message-ID: <Pine.OSF.3.93.960609191716.28968A-100000@duke.usask.ca> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Sun, 9 Jun 1996, Johan Forrer wrote: 


Seems like "nrzi" can decode both packets taken from your TNC's modem and 
your DSP signal source - so that looks like the format is OK. 


Have you looked at the audio levels going to the real TNC when you try your 
DSP signal source? Perhaps they are overdriving the TNC. 


VVVV WV 


I have checked that out and it doesn't make any difference. I wasn't sure 
that it should because the signal that "nrzi" sees is what the modem has 
decoded from the audio input. If the audio were overdriving the modem then 
I would expect the program to see that as errors in the nrzi bitstream 
coming out of the modem but "nrzi" has no trouble decoding the bitstream. 


> Otherwise, I would 
> defininately listen to that audio with an amplified speaker or scope and 
> determine whether is clean and without hum. 


I have listened to the audio and it sounds exactly like the packets I hear 
on the air. I haven't got a scope but I'm going to try to borrow one to 
have a look at the nrzi bitstream from the TNC's modem. Perhaps there are 
subtle timing differences which don't show up due to the nature of my 
sampling program. 


Thanks Johan. 
Pete 


From karn@qualcomm.com Mon Jun 10 19:40:27 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id TAA27043 for <hfsig@tapr.org>; Mon, 10 Jun 1996 
19:40:17 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
RAA29160; Mon, 10 Jun 1996 17:39:42 -0700 (PDT) 

Date: Mon, 10 Jun 1996 17:39:42 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606110039.RAA29160@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.16.19960608194055.3£8fec56@ucs.orst.edu> (message from Johan 
Forrer on Sat, 8 Jun 1996 13:35:25 -@500 (CDT)) 

Subject: Re: [HFSIG:1200] Re: Further thoughts on pulse shaping for HF 


While the usual methods for extracting timing were designed for 
continuous streams of bits, I point out that just about all of our 
applications now involve packetized data of one sort or another. So 
that opens up some alternative methods for timing extraction, like a 
one-shot scheme based on a sync vector in the front of the packet. 


That is, instead of continuously recovering clock from the data 
stream, you estimate it once during each packet and extrapolate it 
from there. This is easy to do by sliding a correlator over the packet 
-- when it hits its peak, you just count off the proper number of 


samples per bit for the rest of the packet. Much easier. 


With even cheap crystals being as good as they usually are, one-shot 
timing schemes work pretty well as long as the packet size is limited 
-- which it is anyway for many other reasons. 


Too bad that one-shot schemes won't work for carrier recovery -- there's 
too much doppler, noise and/or other impairments for this to work, so 
you have to extract it as before with a Costas loop or something similar. 


Phil 


From forrerj@ucs.orst.edu Wed Jun 12 11:01:08 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA29111 for <HFSIG@TAPR.ORG>; Wed, 12 Jun 1996 
11:01:01 -0500 (CDT) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM) 

id AAQ5079; Wed, 12 Jun 1996 09:00:45 -0700 
Date: Wed, 12 Jun 1996 09:00:45 -0700 (PDT) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: HFSIG@tapr.org 
Subject: Re: [HFSIG:1206] Re: Further thoughts on pulse shaping for HF 
In-Reply-To: <65E6D933EE1@fr1l.orst.edu> 
Message-Id: <Pine.OSF.3.91.960612084342 .19054A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Phil, 


While the usual methods for extracting timing were designed for 
continuous streams of bits, I point out that just about all of our 
applications now involve packetized data of one sort or another. So 
that opens up some alternative methods for timing extraction, like a 
one-shot scheme based on a sync vector in the front of the packet. 


VVVV VV MV 


It is true that nearly all communications nowadays have some form of 
header that allows for this kind of one-shot sync. Could you tell us a 
bit more about the sync vector that you are now using. I did follow some 
discussion a while ago about your explorations for a suitable sync vector. 


I now have reasonable clock and data extraction working, but I am working 
on extending the code to look for a sync vector. Although transmission of 
the main data stream is DOQPSK, I use ordinary DPSK for the sync vector. 
I'll do as you suggest - obtain and set the clock at that point it 
recognises the sync vector. My observations have been that there is a 
fraction of a bit's worth slippage across my packets - not too much to be 
of concern. 


I also am considering using offset QPSK and was wondering; would the 
extended Costas loop as for QPSK work for offset QPSK, or would I 


need to change it? 


> 

>That is, instead of continuously recovering clock from the data 

stream, you estimate it once during each packet and extrapolate it 
from there. This is easy to do by sliding a correlator over the packet 
-- when it hits its peak, you just count off the proper number of 
samples per bit for the rest of the packet. Much easier. 


With even cheap crystals being as good as they usually are, one-shot 
timing schemes work pretty well as long as the packet size is limited 
-- which it is anyway for many other reasons. 


Too bad that one-shot schemes won't work for carrier recovery -- there's 
too much doppler, noise and/or other impairments for this to work, so 


you have to extract it as before with a Costas loop or something similar. 


Phil 


VVVV VV VV VV VV VV VV 


The idea here is to use a number of orthogonal channels for data, one 
channel will be unmodulated just to extract doppler. 


The project has been a lot of fun but sure burns time and effort. 
However, I'm learning a lot too. 


--Johan 


From karn@qualcomm.com Wed Jun 12 23:21:21 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id XAA27501 for <hfsig@tapr.org>; Wed, 12 Jun 1996 
23:21:19 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
VAA01103; Wed, 12 Jun 1996 21:20:42 -0700 (PDT) 

Date: Wed, 12 Jun 1996 21:20:42 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606130420.VAA01103@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.OSF.3.91.960612084342 .19054A-100000@ucs.orst.edu> (message from 
Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT)) 

Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF 


>header that allows for this kind of one-shot sync. Could you tell us a 
>bit more about the sync vector that you are now using. I did follow some 


Well, I haven't settled on a final vector yet, but at the moment I'm 
using a 26-bit vector constructed from the 13-bit Barker code (the 
longest-known binary Barker code) with each bit Manchester encoded. 
I.e., a "1" becomes "10" and a "0" becomes "O01". 


This does several things. It adds energy to the total vector, making 


it easier to spot reliably, and it also adds two negative sidelobes 
right next to the main positive lobe. In radar where you don't have 
polarity information and are forced to look at signal envelopes, this 
would be a big drawback. But this is actually an advantage to me since 


I already have signal polarity from the carrier preamble, and the negative 
sidelobes "sharpen" the main lobe, making it less likely for me to lock 
one (or more) samples off the center of the main lobe. 


I've simulated this vector pretty heavily and it seems adequate at the 
nominal modem Eb/NO of 3dB, but I wouldn't mind a little more margin. 


Phil 


From karn@qualcomm.com Wed Jun 12 23:30:57 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id XAA27681 for <hfsig@tapr.org>; Wed, 12 Jun 1996 
23:30:53 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
VAAQ1120; Wed, 12 Jun 1996 21:30:22 -0700 (PDT) 

Date: Wed, 12 Jun 1996 21:30:22 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606130430.VAA01120@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.OSF.3.91.960612084342 .19054A-100000@ucs.orst.edu> (message from 
Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT)) 

Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF 


>I also am considering using offset QPSK and was wondering; would the 
>extended Costas loop as for QPSK work for offset QPSK, or would I 
>need to change it? 


Yes, it works. The scheme I've been using is to sample both I&Q twice 
per symbol, once at the center of the I symbol and again at the center 
of the Q symbol. Two of these samples obviously become the recovered 
data symbols. The out-of-phase samples (e.g., the one of the Q-channel 
taken at the I-channel sampling instant) has its sign flipped by the 
polarity of the current in-phase sample. Then the polarity corrected 
out-of-phase Q-channel samples are subtracted from the polarity 
corrected out-of-phase I-channel samples, producing the phase 
residuals that my loop attempts to minimize in a least-squares 
fashion. 


This is basically the classic decision-directed 4-phase costas loop, 
implemented in a sampled system. 


I've been looking more closely at your exact question over the past 
day or two. With my current scheme it xseemsx that with SQPSK (but not 
plain QPSK) there exist data patterns that produce no phase detector 
output even when there is a carrier phase error. If you number the 


four phase states 1-2-3-4, imagine an encoded phase sequence that goes 
1-2-3-4-1-2-3-4 (or 4-3-2-1-4-3-2-1). (This corresponds roughly to an 
unmodulated carrier offset above or below the real carrier). In this 
case, all of the out-of-phase symbols are in the process of changing 
when they're sampled by the in-phase symbol, leaving no residual even 
when there's a carrier phase error. 


The scheme still seems to work, at least for the random-like data 
produced by the convolutional coder and interleaver, but this 
phenomenon still bothers me. If nothing else, it means that the gain 
of the "loop" (and the speed at which it converges) depends on the 
signal pattern as well as the amplitude of the signal. Although this 
doesn't actually affect the error performance of the modem (since I 
operate in an a-posteriori batch mode where I repeatedly crunch each 
block of symbols until I find the steady-state maximum likelihood 
carrier phase and frequency), it does affect the cost in CPU cycles. 


More when I figure this all out for myself. 
Phil 


From karn@qualcomm.com Wed Jun 12 23:34:53 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id XAA27983 for <hfsig@tapr.org>; Wed, 12 Jun 1996 
23:34:50 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
VAA01148; Wed, 12 Jun 1996 21:34:19 -0700 (PDT) 

Date: Wed, 12 Jun 1996 21:34:19 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606130434.VAA01148@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.OSF.3.91.960612084342 .19054A-100000@ucs.orst.edu> (message from 
Johan Forrer on Wed, 12 Jun 1996 11:09:06 -0500 (CDT)) 

Subject: Re: [HFSIG:1207] Re: Further thoughts on pulse shaping for HF 


>The idea here is to use a number of orthogonal channels for data, one 
>channel will be unmodulated just to extract doppler. 


How well does the carrier reference channel work in practice, given 

multipath? Can you really just lock a loop to it and derive carrier 
phase for all your other channels, eliminating all the squaring (or 

worse) losses inherent in suppressed carrier systems? 


Phil 


From forrerj@ucs.orst.edu Thu Jun 13 11:38:37 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA27391 for <hfsig@tapr.org>; Thu, 13 Jun 1996 
11:38:34 -0500 (CDT) 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 

id AA14059; Thu, 13 Jun 1996 09:38:27 -0700 
Message-Id: <1.5.4.16.19960613180144.3f£78574@ucs.orst.edu> 


X-Sender: forrerj@ucs.orst.edu 

X-Mailer: Windows Eudora Light Version 1.5.4 (16) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 13 Jun 1996 10:01:44 -0800 

To: hfsig@tapr.org 

From: Johan Forrer <forrerj@ucs.orst.edu> 

Subject: Re: [HFSIG:1210] Re: Further thoughts on pulse shaping for HF 


Phil, 


At 11:49 PM 6/12/96 -0500, you wrote: 

>>The idea here is to use a number of orthogonal channels for data, one 
>>channel will be unmodulated just to extract doppler. 

> 

>How well does the carrier reference channel work in practice, given 
>multipath? Can you really just lock a loop to it and derive carrier 
>phase for all your other channels, eliminating all the squaring (or 
>worse) losses inherent in suppressed carrier systems? 

> 

>Phil 

> 

> 


That's a good question. Perhaps someone like Hakan, who are more familiar 
with MIL-STD 188 or STANAG modems could tell us more about that. I have seen 
the idea used for doppler compensation in both the 39 and 16 tone modems for 
this purpose. Perhaps to deal with a kind of doppler that affects the block 
of frequencies as a whole instead of only selective channels. As to how 
valid or effective that is, I really don't know. 


Someone care to comment? 
--Johan 


From forrerj@ucs.orst.edu Thu Jun 13 11:38:40 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA27392 for <hfsig@tapr.org>; Thu, 13 Jun 1996 
11:38:37 -0500 (CDT) 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AAQ4085; Thu, 13 Jun 1996 09:38:22 -0700 
Message-Id: <1.5.4.16.19960613180138.3ff7efdO@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 13 Jun 1996 10:01:38 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1209] Re: Further thoughts on pulse shaping for HF 


Hi Phil, 


At 11:49 PM 6/12/96 -0500, you wrote: 

>>I also am considering using offset QPSK and was wondering; would the 
>>extended Costas loop as for QPSK work for offset QPSK, or would I 
>>need to change it? 

> 

>Yes, it works. The scheme I've been using is to sample both I&Q twice 
>pexr symbol, once at the center of the I symbol and again at the center 
>of the Q symbol. Two of these samples obviously become the recovered 
>data symbols. The out-of-phase samples (e.g., the one of the Q-channel 
>taken at the I-channel sampling instant) has its sign flipped by the 
>polarity of the current in-phase sample. Then the polarity corrected 
>out-of-phase Q-channel samples are subtracted from the polarity 
>corrected out-of-phase I-channel samples, producing the phase 
>residuals that my loop attempts to minimize in a least-squares 
>fashion. 


Thanks - good to know that. 


> 

>This is basically the classic decision-directed 4-phase costas loop, 
>implemented in a sampled system. 

> 

>I've been looking more closely at your exact question over the past 
>day or two. With my current scheme it xseemsx that with SQPSK (but not 
>plain QPSK) there exist data patterns that produce no phase detector 
>output even when there is a carrier phase error. If you number the 
>four phase states 1-2-3-4, imagine an encoded phase sequence that goes 
>1-2-3-4-1-2-3-4 (or 4-3-2-1-4-3-2-1). (This corresponds roughly to an 
>unmodulated carrier offset above or below the real carrier). In this 
>case, all of the out-of-phase symbols are in the process of changing 
>when they're sampled by the in-phase symbol, leaving no residual even 
>when there's a carrier phase error. 


I follow - interesting that SQPSK has that anomaly. I was going to ask 
whether you are using a scrambler as that would reduce the recurrence of 
such a pattern, but your convolutional coding and interleaver will probably 
have the same effect to randomize the pattern. 


> 

>The scheme still seems to work, at least for the random-like data 
>produced by the convolutional coder and interleaver, but this 
>phenomenon still bothers me. If nothing else, it means that the gain 
>of the "loop" (and the speed at which it converges) depends on the 
>signal pattern as well as the amplitude of the signal. Although this 
>doesn't actually affect the error performance of the modem (since I 
>operate in an a-posteriori batch mode where I repeatedly crunch each 
>block of symbols until I find the steady-state maximum likelihood 
>carrier phase and frequency), it does affect the cost in CPU cycles. 


I played with a decision-directed scheme for a while that, at the middle of 
the symbol, found the closest constellation point, and then determines 


whether the received constellation needed to be rotated clockwise or 
anti-clockwise. When the set of constellation points were {(1 0), (0 -1), 
(-1 0), (0 -1)%, then either I or Q needed to be zero. One could then use 
this non-zero offset as an (magnitude, direction) error estimate to be used 
for loop control. This worked wonderfully until I started using RC pulse 
shaping - the zero-crossing transitions for the RC pulses just played havoc. 
At that point I switched to the extended Costas loop that took care of it, 
however, as you said in an earlier posting, that type of loop drives I and Q 
maximal and in my case, the transmitted and received constallations are 
offset by a constant 45 degrees. That does not bother differential coding as 
long as it is a stable lock, which is the case. I find that I can start the 
demodulator midst of a random data sequence, obtain and hold lock - even for 
33 second packets. 


> 

>More when I figure this all out for myself. 
> 

>Phil 

> 

> 


Let us know the outcome - I'm curious. 
--Johan 


From zs6awk@global.co.za Fri Jun 14 16:51:36 1996 

Received: from lin01.global.co.za (lin01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA03934 for <hfsig@tapr.org>; Fri, 14 Jun 1996 
16:50:03 -0500 (CDT) 

Received: from mail.global.co.za ([196.3.168.58]) by linO1.global.co.za 
(8.7.3/8.7.3) with SMTP id XAA27977 for <hfsig@tapr.org>; Fri, 14 Jun 1996 
23:48:12 -0200 (GMT) 

Message-Id: <199606150148. XAA27977@1in01.global.co.za> 

X-Sender: zséawk@mail.global.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 14 Jun 1996 23:49:42 +0200 

To: hfsig@tapr.org 

From: zs6éawk@global.co.za (Danie Brynard) 

Subject: re pos of filter vs nyquist 


I have been playing around with simulations to see if the position of a FIR 
filter is important relative to the Nyquist frequency. Thus if I have a BPF 
of say arbitrary passband and stopband does it matter where I place this 
filter in the frequency range OHz to Fnyquist Hz ? (Fnyq=Fs/2) 


According to my simulations it does not matter but I am not convinced. In 
the analog world the rule is: the higher the freqency the more difficult it 
is to make the same BPF. 


Is wordlength or calculation precision perhaps the answer ? Is the number of 
cycles per unit time of the wanted signal perhaps the answer ? 


Could somebody give me a ‘gut-feel' answer ? In other words a layman 
explanation why it does/does not matter where one puts the filter. 


I hope I explained myself well enough. Looking forward to all the 
interesting replies :-) 


73 danie zs6éawk@global.co.za 


From hakan.bergzen@enator.se Sat Jun 15 10:40:42 1996 
Received: from gk.enator.se (ns.enator.se [147.13.200.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id KAA18040 for <hfsig@tapr.org>; Sat, 15 Jun 1996 
10:40:31 -0500 (CDT) 
Received: from janus.vxo.telub.se ([147.13.8.25]) by gk.gk.enator.se with SMTP id 
<35746>; Sat, 15 Jun 1996 17:40:37 +0100 
Received: from noak.vxo.enator.se by janus.vxo.telub.se with SMTP (PP) 
id <11592-0@janus.vxo.telub.se>; Sat, 15 Jun 1996 17:35:10 +0200 
Received: by noak with Microsoft Mail id <31CDE3D2@noak>; 
Sat, 15 Jun 96 17:39:46 +02 
From: "Bergzen Hakan, KARL" <hakan.bergzen@enator.se> 
To: hfsig <hfsig@tapr.org> 
Subject: Re: Further thoughts on pulse shaping for HF 
Date: Sat, 15 Jun 1996 16:39:00 +0100 
Message-ID: <31CDE3D2@noak> 
Return-Receipt-To: HABE <hakan.bergzen@enator.se> 
Encoding: 67 TEXT 
X-Mailer: Microsoft Mail V3.0 
MIME-Version: 1.0 
Content-Type: Text/plain; charset="US-ASCII" 
Content-Transfer-Encoding: 7bit 


Johan, 


I have not been able to monitor this group for some time, just trying to 
catch up, when I saw your reference to me. Even though I doubt I would have 
some information which not you and Phil already knows (I am very impressed 
of both of you being able to give the rest of us elaborate responses to our 
various questions, comments and ideas). This probably also goes for several 
silent readers of this group. 


>>>The idea here is to use a number of orthogonal channels for data, one 
>>>channel will be unmodulated just to extract doppler. 

>> 

>>How well does the carrier reference channel work in practice, given 
>>multipath? Can you really just lock a loop to it and derive carrier 
>>phase for all your other channels, eliminating all the squaring (or 
>>worse) losses inherent in suppressed carrier systems? 

>> 

>That's a good question. Perhaps someone like Hakan, who are more familiar 
>with MIL-STD 188 or STANAG modems could tell us more about that. I have 
seen 

>the idea used for doppler compensation in both the 39 and 16 tone modems 


for 

>this purpose. Perhaps to deal with a kind of doppler that affects the block 
>of frequencies as a whole instead of only selective channels. As to how 
>valid or effective that is, I really don't know. 


The parallel tone modes within MIL-STD-188-110A use a special doppler 
correction tone, which will run continuously. It is the lowest tone in both 
modes (605 Hz for the 16-tone mode and 393.75 Hz for the 39-tone mode). It 
is only used for doppler correction, thus enabling the DSP to adjust the 
frequency offset for all data tones up or down correspondingly before symbol 
demodulation. 


Both modes use BDPSK and QDPSK (depending on the data rate selected). At the 
lower data rates DPSK and in-band diversity combining are used. The 39-tone 
mode also use interleavers. Since only differential encoding is used the 
symbol decoding problem is more or less eliminated (I dont think it is 
possible to extract a carrier phase for one tone and use it for any other 
tone). 


The protocol uses an initial preamble. The 39-tone mode use a 3-part 
preamble of different data tones all-in-all 23 signal elements (An extended 
preamble uses 97 signal elements). The data to be sent is divided into 
blocks. Each data block starts with a block sync. The block length depends 
on interleaver depth and data rate selected. A transmission is ended with an 
End-of-message sequence. 


I think it would be a good idea to include a superb feature defined in the 
serial tone mode of the MIL-STD-188-110A, namely the Autobaud function. 
Within the initial preamble (and the re-occuring preamble enabling re-sync) 
the data rate and interleaver setting is encoded. This enables a receiving 
modem to automatically make the correct parameter setting and receive the 
message. The transmitting modem can by itself decide upon the most suitable 
data rate/interleaver depth.This makes it e.g. possible to easily construct 
adaptive ARQ schemes. 


The trend in Europe and the U.S. seems to go from parallel tone modems to 
serial tone modems. They are more tricky to construct (including adaptive 
channel equalizers) but they show better performance because of their better 
utilization of the available channel (a sort of narrow-band SS, really). 
Though recent Australian studies (DSTO) using parallel tone modems together 
with trellis coding claims to perform better than serial tone modems. 


For what it's worth... 
Hakan (hakan.bergzen@enator.se) 


From JSANFORD@INFI.NET Sat Jun 15 20:05:03 1996 
Received: from mh004.infi.net (mailhost.infi.net [205.219.238.95]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ7794 for <hfsig@tapr.org>; Sat, 15 Jun 1996 
20:04:48 -0500 (CDT) 
Received: from pa9dsp3.orf.infi.net by mhO004.infi.net with SMTP 

(Infinet-S-3.3) id VAA28286; Sat, 15 Jun 1996 21:04:17 -0400 (EDT) 
Message-Id: <199606160104.VAA28286@mh004.inf£1i.net> 


X-Sender: jsanford@infi.net 

X-Mailer: Windows Eudora Light Version 1.5.2 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Sat, 15 Jun 1996 21:04:37 -0400 

To: hfsig@tapr.org 

From: Jim Sanford <JSANFORD@INFI.NET> 

Subject: Re: [HFSIG:1190] Re: QPSK BANDWIDTH ? 


Phil 
Forgive the long delay . .. the cost of my job which takes me 
to sea . 


Your comment about filters is part of why I'm hoping to do the thing 
with simple chips and do ALL filtering in DSP. Of course, Ulrich Rhode 
will remind me that a "ROOFING" filter would improve s/n in the IF . 


Goal is acceptable performance at low cost and ease of duplication. I'm 
hoping to turn this project into a kit for our club . 


At 03:22 PM 6/4/96 -0500, you wrote: 

>> 1. For what platform are you doing the OQPSK 

>>satellite modem? I have 2 dsp-12's and would love to 

>>beta test . 

> 

>The platform is a generic 486 or Pentium PC running my KA9Q NOS TCP/IP 
>package. The modem will be integrated in as an interface driver for a 
>SoundBlaster 16 card xwithout*x any special DSP chips. 

> 

>Your work with the ‘digital friendly' receiver sounds very 
>interesting! I do hope that whatever you come up with can be easily 
>replicated by the average amateur -- in my experience, that's where 
>many promising amateur hardware projects fall down. It's the main 

I absolutely agree... 


>reason I've become so interested in using mass-market PC hardware to 
>the greatest possible extent, doing everything else in software. But 
>there are definite limits to the available hardware (particularly in 
>the radios) so your work is most welcome. I agree, this stuff ought 

>not to be as expensive and complicated as it seems to be. 

I've been somewhat against using stuff in a PC because I hate the thought 
of tying up a PC for a single function, but you've got a GREAT point 
about the cost of mass market hardware vs anything for the much smaller 
ham market. And, as costs of PC's drop . 


I'm already dedicating a 486/overdrive to the pacsats, so, what's another 


cheap 486 on the network . . . <grin> 
Thanks again for all you've done....73, Jim 
wb4gcs 


>The guy behind the Fox-Tango table, being used to selling very sharp 
>and narrow crystal filters for HF contest and DX use, couldn't figure 


>out why in the world I would want to make my rig go xwider*x. Ah, the 
>"narrowband mindset" seems pretty well entrenched. :-) 
> 


From zs6awk@global.co.za Sun Jun 16 14:55:40 1996 

Received: from linO1.global.co.za (linO01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA25148 for <hfsig@tapr.org>; Sun, 16 Jun 1996 
14:55:30 -0500 (CDT) 

Received: from anx_80.global.co.za (anx_80.global.co.za [196.3.164.130]) by 
linO1.global.co.za (8.7.3/8.7.3) with SMTP id VAA03929 for <hfsig@tapr.org>; Sun, 
16 Jun 1996 21:53:37 -0200 (GMT) 

Message-Id: <199606162353.VAA03929@1in01.global.co.za> 

X-Sender: zséawk@mail.global.co.za (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 16 Jun 1996 21:55:02 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: Re: [HFSIG:868] Re: DSP Tools 


Phil is there perhaps a book that you can suggest if one wants to read more 
about the inner working of the 486 and Pentuim and also on real-time 
programming of it in assembler ? Something perhaps like ‘asm programming on 
the Pentuim for beginners' :-) 


I am hooked onto the Motorola DSP56xxx family but is interested in your ideas.. 


danie zs6éawk 
zs6awk@global.co.za 


>At 06:22 PM 2/8/96 -0600, you wrote: 

> 

>>As for DSP development platforms. Both TI (www.ti.com) and Motorola 
>>(www.motorola.com) have inexpensive DSP Starter Kits (DSK) (TI) or 
>>Evaluation Modules (EVM) (Motorola). The TI C5X DSK (p/n TMDS3200051) costs 
>>$99.00 and the Motorola EVM560002 costs $149.00. I own the later and have 
>>the former on order. 

> 

>Don't forget that you can do serious DSP on general purpose computers without 
>a DSP board. Pentiums and the faster 486s rival many dedicated DSPs, especially 
>on floating point computations. 

> 

>Phil 

> 

> 


From karn@unix.ka9q.ampr.org Sun Jun 16 16:51:29 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA29942 for <hfsig@tapr.org>; Sun, 16 
Jun 1996 16:51:25 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id OAA15153; 
Sun, 16 Jun 1996 14:51:19 -0700 (PDT) 


Date: Sun, 16 Jun 1996 14:51:19 -0700 (PDT) 

Message-Id: <199606162151.0AA15153@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <199606162353 .VAA03929@1in01.global.co.za> (zs6éawk@global.co.za) 
Subject: Re: [HFSIG:1216] Re: DSP Tools 

Reply-To: karn@qualcomm.com 


Well, the standard Intel programmer's references are pretty good. They 
tell you all you really need to know to optimize DSP code on the 
Pentium, such as instruction clock counts and considerations on how to 
keep the pipelines full. 


Phil 


From Robert.Glassey@nmp.nokia.com Mon Jun 17 04:27:27 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAAQ2862 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
04:27:12 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA10028 for <hfsig@tapr.org>; Mon, 
17 Jun 1996 12:26:07 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA110443452; Mon, 17 Jun 1996 12:24:12 +0300 
X-Openmail-Hops: 2 
Date: Mon, 17 Jun 96 10:17:35 +0100 
Message-Id: <H000029201ddaf£7@MHS> 
Subject: BTL performance tests 
Mime-Version: 1.0 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=IS0O-8859-1; name="BTL" 
Content-Transfer-Encoding: 7bit 


Hi all, 

Over the weekend I did a few performance tests on my PC- 

Sound Blaster based DSP RTTY modem (BTL), and compared it 

with my PK232MBX. Here's the results. Any coments welcome. 
PK232MBX BTL Ver 0.2 


1 Noise performance: 15dB 12dB 
Eb/No for BER=10‘%-2 


2 Adjacent channel rejection (+500Hz 98 baud RTTY) 
2a For 3dB rise in 104-2 Eb/No: 
Square pulse interferer 9dB 30dB 


Raised cosine pulse interferer - 32dB 


2b For clean wanted signal, 10-2 BER: 
Square pulse interferer 16dB 32dB 


Raised cosine pulse interferer - 35dB 


Observations: 


1. The BER taken includes errors due to both sync 
errors and data bit errors. For both modems 
relative contributions were about 50-50. 

If a bit synchronous mode were used rather than 
asynchronous baudot, BER would be half. My 
measurements show this is equivelent to a 1dB 
improvement in Eb/No for both modems. 


2. Two different interferer types were used. Both were 
phase continous FSK, 98 baud baudot, centred 500Hz 
above the wanted signal (wanted 1275/1445, interferer 
1775/1945) Standard RTTY has a square pulse shape 
resulting in high adjacent channel power. (-30dB @ 
500Hz) This limited measurements (and is a real on air 
limit too) However I tried shaping the interferering 
FSK pulses with raised cosine edges (shaped 64 of 82 
samples). ACP was reduced to -45dB @ 500Hz. Using this 
interferer, the true performance of the modem could be 
determined. This shaping reduced the interference RMS 
level to 72% and this was taken into account. 


The minimum signal level without intefernce was found 
to be 1 ADC step peak to peak, with dithering from the 
noise of almost 3 ADC steps peak-peak. (signals were 
calculated in 16 bits then quantised to 8 bits to allow 
noise dithering). At this level performance was still 
12dB Eb/No @ BER 104-2. This minimum signal level was 
44dB below the inteference level used above. Thus 
quantisation was not a limiting factor in the above 
measurements. Lower levels were possible but Eb/No was 
worsened and quantisation boundries became significant. 


Measurement Technique: 

1. Eb/No measurements 

Sampling rate was 8KHz 

The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
0.71 

The noise was generated by a 24bit maximum length PRN 
generator (poly=0x8D0000), doing 8 shifts per sample to get 


an 8 bit uniform random noise source. RMS to peak ratio of a 
uniform random noise source = 0.58 


I have assumed a uniform distribution is OK since after 
bandpass filtering and integration the noise distribution 
aproaches gausian. (roughly speaking, the noise is averaged 
over the bit period, ie 178 samples, making the noise 
gausian by summation) 


For Eb/No calculations I have used the RMS levels at the 
8kHz sample rate. 


Peak-peak levels of signal=45 and noise=128 becomes 12db 
Eb/No thus: 


Eb/No = 20*log10 ((45/2 * 0.71) / (128/2 * 0.58)) 
+ 10x*log10(4000 Hz) - 10*log10(45 BPS) 
12.2 dB 


2. Adjacent channel measurements 
The signals are described above. 


The interferer baud rate of 98 baud was chosen to try to 
ovoid synchronisation between the wanted and interferer 
so errors would appear more random, hopefully giving a 
more accurate BER. However it does make the interferer 
wider, but pulse shaping dealt with that. This may not 
be the best method. 


Results are given for two different cases. 1. Fora 

3dB rise in the Eb/No required for 10-2 BER, and 

2. The interference level that gives a BER of 104-2 
when the wanted signal is clean. These figures show 
respectivly the degradation in weak signal performance, 
and the maximum tolerable adjacent channel signal level 
when the wanted signal is clean. 


So, 12dB Eb/No doesn't sound all that hot, does it? But is this what 
should be expected for FSK without ECC? Eb/No would be 11dB if a bit 
synchronous mode was used. These are for a BER of 10%-2. 


Cheers, 


Rob 


From karn@unix.ka9q.ampr.org Mon Jun 17 05:16:20 1996 
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAAQ4098 for <hfsig@tapr.org>; Mon, 17 


Jun 1996 05:16:11 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id DAA00188; 
Mon, 17 Jun 1996 03:16:05 -0700 (PDT) 

Date: Mon, 17 Jun 1996 03:16:05 -0700 (PDT) 

Message-Id: <199606171016 .DAAQ0188@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <199606130430.VAA01120@servo.qualcomm.com> (karn) 

Subject: Re: [HFSIG:1209] Re: Further thoughts on pulse shaping for HF 

Reply-To: karn@qualcomm.com 


FYI, more about offset QPSK vs conventional QPSK. 


It looks as though the advantages of staggered (offset) QPSK are 
outweighted by the disadvantages, so I've switched to straight QPSK. 


There are two main advantages of offset QPSK: 1) less envelope droop 
when the signal is bandlimited, which turns into less sideband 
regrowth when the signal is nonlinearly amplified, and 2) less 
crosstalk between channels when the carrier phase reference is 
inaccurate. 


I originally chose SQPSK for reason #2; I don't really care too much 
about #1 since I am going to operate in a power-controlled regime 
where I assume there'll be a fair amount of transmit headroom most of 
the time, hence plenty of linearity. And even if there were sideband 
regrowth it wouldn't be as important a source of interference since 
I'm already operating at very low S/N ratios thanks to power control 
and coding. 


But it turns out that the crosstalk resistance of SQPSK is largely 
mitigated by greatly increased pattern-sensitive jitter in the carrier 
recovery system. In other words, although SQPSK has increased carrier 
phase jitter tolerance, it inherently increases the jitter of the 
recovered carrier which squanders the improved performance. 


I couldn't find a precise quantitative formulation for this, but from 
what I saw it looks like any gains SQPSK might have (especially at the 
very low Es/NOs I'm using) are small or even negative. And the last 
straw was that SQPSK is harder to implement than straight QPSK. So 
I've switched to straight QPSK. 


Phil 


From karn@unix.ka9q.ampr.org Mon Jun 17 05:47:56 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAAQ5064 for <hfsig@tapr.org>; Mon, 17 
Jun 1996 05:47:51 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.3/8.6.12) id DAA00230; 
Mon, 17 Jun 1996 03:47:44 -0700 (PDT) 

Date: Mon, 17 Jun 1996 03:47:44 -0700 (PDT) 


Message-Id: <199606171047 .DAAQO0230@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.16.19960613180138 .3f££7efdO@ucs.orst.edu> (message from 
Johan Forrer on Thu, 13 Jun 1996 11:58:25 -0500 (CDT)) 

Subject: Re: [HFSIG:1212] Re: Further thoughts on pulse shaping for HF 

Reply-To: karn@qualcomm.com 


>I follow - interesting that SQPSK has that anomaly. I was going to ask 
>whether you are using a scrambler as that would reduce the recurrence of 
>such a pattern, but your convolutional coding and interleaver will probably 
>have the same effect to randomize the pattern. 


Re the anomaly I described (certain data patterns killing the SQPSK 
phase detector) I'm now not exactly sure that this is real. But it 
xdoesx seem from reading the books that there is a pattern-sensitive 
phase jitter in SQPSK that's not present in plain QPSK, and the 
problem gets worse when you tightly filter the signal. So that's why 
I've switched from SQPSK to plain QPSK. Simplified the code, too. 


Re scramblers, no, I'm not scrambling. Yes, the convolutional coding 
and interleaving does a pretty good job. It certainly sounds noiselike 
except when I send a big block of zeroes, which come out as a tone. 
But the loop can track this fine anyway (remember I'm doing one-shot 
symbol timing up front). 


Re your discussion of decision-directed carrier recovery, it works 
great when the Es/NO is high enough to work without coding. But at the 
Es/NO ratios I'm using with my coding, there are plenty of errors in 
the decisions because they're made by simple slicing, without benefit 
of any error correction. So many of the phase detector outputs are 
wrong (though not most, since the error rate is still less than 50%). 
This adds noise to the feedback loop over and above the noise in the 
input signal. In the literature this is called "squaring loss" 
(although strictly speaking that applies only to BPSK -- in QPSK it 
should be called "4th power loss"). Squaring loss is a function of 
loop design, Es/NO and of the loop signal-to-noise ratio. 


Squaring loss forces you to use a much narrower loop filter than you'd 
otherwise use in order to maintain an acceptably high S/N ratio within 
the loop. That means you get pretty sensitive to doppler. 


Another good illustration of how trying to conserve bandwidth (e.g., 
by using QPSK instead of BPSK in the first place) often ends up 
forcing you to use more power per bit even when it shouldn't -- ideal 
QPSK and BPSK (with perfect carrier recovery) have exactly the same 
Eb/NO requirements. I'm still having a hard time getting to within 1 
dB of the theoretical code performance in my QPSK modem. 


Phil 


From LANIER.R.A-@smtpgty.bwi.wec.com Mon Jun 17 07:25:59 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 


(8.7.5/8.7.3/1.9) with SMTP id HAAO09672; Mon, 17 Jun 1996 07:25:51 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron.bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA24688; Mon, 17 Jun 1996 07:46:00 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1C54EE50; Mon, 17 Jun 96 08:26:13 
-0400 
Mime-Version: 1.0 
Date: Mon, 17 Jun 1996 08:16:07 -0400 
Message-Id: <1C54EE50.1858@smtpgty.bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
To: hfsig@tapr.org, ss@tapr.org 
Subject: Sinewave generator source code 
Content-Type: multipart/mixed; boundary="IMA.Boundary .273410538" 


--IMA.Boundary .273410538 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


For what its worth, I found the article I was looking for (Radio 
Electronics, October 1991). The author used a C program to generate 
the data for the EPROM feeding into the DAC. His source code is shown 
below. I also attached a sample output file to this note. The EPROM is 
a standard 2716. Of course, the code can be modified to suit your 
needs. 


I intend to use this to produce a LUT (Look Up Table) inside a Xilinx 
FPGA. I want to use the LUT as the basis for a QPSK modulator. If I 
can feed serial data into the Xilinx, I can then produce I and Q 
components and use these as inputs into a custom up/down counter. The 
output of the counter will feed into the LUT. The output of the LUT 
would then feed into an external DAC. I'm not sure if this can work, 
but I will anyone who cares about this now what results I came up 
with. 


73s de 
Tony, KE4ATO 


/*x This program calculates the value of the sine function 
offset so that the 4th and 1st quadrants cause a code 
from @ to 255. Code is generated to fill a 2048 byte prom 
(2716 or equivalent) for a full circle of 2«pi radians. 
Other size memory may be used by changing the value of 
bytes in the declaration table. 


*/ 


dtinclude <stdio.h> 
dtinclude <math.h> 


main () 


z 


double p=0; /* phase input to sine function x/ 
double S=0; /* output value of the true sine function x/ 
int s; /* amplitude truncated to 8 bits x/ 
double sin(); /* true sine function x/ 
double pi=3.141592654; 
int addr=0; /x address of EPROM x/ 


int bytes=2048; /*x size of EPROM in bytes x/ 


printf(" 0 1 2 3 4 5 6 7 8"); 
printf(" 9 A B C D E F \n"); 
while (addr < bytes) 
7) 
if (addr % 16 == Q) 
printf ("\n%4x "| addr); 
p = 2.0*pix( (double) addr)/( (double) bytes); 
S = 127.5*(1.0 + sin(p - pi/2.0)); /* gives 0 at -90 deg x/ 
s = ( (int) S); /* convert to integer x/ 
if (S - ( (double) s) >= 0.5) /* rounds if necessary x/ 
St+; 
printf(" %2x", S); 
addr++; /x increment address x/ 
$ 
return (0); 
$ 


--IMA.Boundary .273410538 

Content-Type: text/basic; name="output.txt" 
Content-Transfer-Encoding: 7bit 

Content-Description: MS-DOS text file 
Content-Disposition: attachment; filename="output.txt" 


0 41 2 3 4 #5 6 7 8 9 A BC D 


m 
mn 


0) 0) 0) 0) 0) 0) 0) 0) 0 0) (0) 0) 0 (0) 0) (0) (0) 
10 0) 0) 0) 0 0) 0) 0) 0) 0 0) 0 0 (0) 1 1 1 
20 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
30 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 
40 2 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 
50 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 
60 5 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 
70 7 8 8 8 8 8 8 8 9 9 9 9 9 9 9 a 
80 a a a a a a b b b b b b Cc Cc Cc Cc 
90 Cc Cc d d d d d d e e e e e f f f 
ad f f f 10 10 10 10 10 11 11 11 #11 #11 «#12 «12 «12 
bO 12 12 13 13 13 13 13 #14 14 #14 #14 «14 «15 «15 #15 #15 
cO 15 16 16 16 16 17 17 #17 #17 #17 #18 #18 #18 «18~«19 «419 
do 19 19 ta ta ta 1a 1b 1b 1b 1b 1b 1c 1c 1c 1c 1d 
e0 id 1d 1d te te te te 1f 1f 1f 1f 20 20 20 21 21 
£0 21 21 22 22 22 22 23 23 23 23 24 24 24 25 25 25 

100 25 26 26 26 26 27 27 27 28 28 28 28 29 29 29 2a 
110 2a 2a 2a 2b 2b 2b 2c 2c 2c 2d 2d 2d 2d 2e 2e 2e 
120 2f 2f 2f 30 30 30 30 31 31 31 32 32 32 33 #33 «33 


130 
140 
150 
160 
170 
180 
190 
1a0 
1b0 
1c0 
1d0 
1e0 
1£0 
200 
210 
220 
230 
240 
250 
260 
270 
280 
290 
2a0 
2b0 
2cO 
2d0 
2e0 
2£0 
300 
310 
320 
330 
340 
350 
360 
370 
380 
390 
3a0 
3b0 
3c0 
3d0 
3e0 
3£0 
400 
410 
420 
430 
440 
450 
460 
470 


34 
39 
3e 
43 
49 
Af 
55 
5a 
61 
67 
6d 
73 
79 
80 
86 
8c 
92 
98 
9e 
a5 
aa 
bO 
b6 
bc 
c1 
c6 
cb 
do 
d5 
da 
de 
e2 
e6 
ea 
ed 
f0 
f3 
£5 
f8 
fa 
fb 
fd 
fe 
fe 
ff 
ff 
ff 
fe 
fe 
fd 
fb 
fa 
f8 


34 
39 
3e 
44 
49 
Af 
55 
5b 
61 
67 
6d 
73 
7a 
80 
86 
8c 
93 
99 
of 
a5 
ab 
b1 
b6 
be 
cl 
c7 
cc 
di 
d5 
da 
de 
e2 
e6 
ea 
ed 
f0 
£3 
£5 
f8 
fa 
fb 
fd 
fe 
fe 
ff 
ff 
ff 
fe 
fe 
fc 
fb 
£9 
£7 


34 
39 
3f 
44 
4a 
Af 
55 
5b 
61 
67 
6e 
74 
7a 
80 
87 
8d 
93 
99 
of 
a5 
ab 
b1 
b7 
be 
c2 
c7 
cc 
di 
d6 
da 
de 
e3 
e6 
ea 
ed 
f0 
£3 
£6 
f8 
fa 
fb 
fd 
fe 
fe 
ff 
ff 
ff 
fe 
fe 
fc 
fb 
£9 
£7 


34 
3a 
3f 
44 
4a 
50 
56 
5c 
62 
68 
6e 
74 
7a 
81 
87 
8d 
93 
9a 
ad 
a6 
ac 
b1 
b7 
bd 
c2 
C7 
cc 
di 
d6 
da 
df 
e3 
e7 
ea 
ed 
f0 
£3 
£6 
f8 
fa 
fb 
fd 
fe 
fe 
ff 
ff 
ff 
fe 
fd 
fc 
fb 
£9 
£7 


35 
3a 
3f 
45 
4a 
50 
56 
5c 
62 
68 
6e 
75 
7b 
81 
87 
8e 
94 
9a 
ad 
a6 
ac 
b2 
b7 
bd 
c2 
c8 
cd 
d2 
d6 
db 
df 
e3 
e7 
ea 
ee 
£1 
£3 
£6 
f8 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fb 
£9 
£7 


35 
3a 
40 
45 
Ab 
51 
56 
5c 
62 
69 
6£ 
75 
7b 
81 
88 
8e 
94 
9a 
ad 
a6 
ac 
b2 
b8 
bd 
c3 
c8 
cd 
d2 
d7 
db 
df 
e3 
e7 
eb 
ee 
£1 
£4 
£6 
f8 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fb 
£9 
£7 


35 
3b 
40 
45 
Ab 
51 
57 
5d 
63 
69 
6£ 
75 
7C 
82 
88 
8e 
95 
9b 
al 
a7 
ad 
b2 
b8 
be 
c3 
c8 
cd 
d2 
d7 
db 
e0 
e4 
e7 
eb 
ee 
£1 
£4 
£6 
f8 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fb 
£9 
£7 


36 
3b 
40 
46 
Ab 
51 
57 
5d 
63 
69 
70 
76 
7C 
82 
88 
8£ 
95 
9b 
al 
a7 
ad 
b3 
b8 
be 
c3 
c9 
ce 
d2 
d7 
dc 
e0 
e4 
eg 
eb 
ee 
£1 
£4 
£6 
f8 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
£9 
£7 


36 
3b 
41 
46 
Ac 
52 
58 
5d 
64 
6a 
70 
76 
7C 
83 
89 
8f£ 
95 
9b 
a2 
a7 
ad 
b3 
b9 
be 
c4 
c9 
ce 
d3 
d7 
dc 
e0 
e4 
eg 
eb 
ee 
£1 
£4 
£6 
£9 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
£9 
£6 


36 
3c 
41 
47 
Ac 
52 
58 
5e 
64 
6a 
70 
77 
7d 
83 
89 
8£ 
96 
9c 
a2 
a8 
ae 
b4 
b9 
bf 
c4 
c9 
ce 
d3 
d8 
dc 
e0 
e4 
e8 
eb 
ef 
£2 
£4 
£7 
£9 
fa 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
f8 
£6 


37 
3c 
41 
47 
Ad 
52 
58 
5e 
64 
6a 
71 
77 
7d 
83 
8a 
90 
96 
9c 
a2 
a8 
ae 
b4 
ba 
bf 
c4 
ca 
cf 
d3 
d8 
dc 
e1 
e4 
e8 
ec 
ef 
f2 
£4 
£7 
£9 
fb 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
f8 
£6 


37 
3c 
42 
47 
Ad 
53 
59 
5f 
65 
6b 
71 
77 
7e 
84 
8a 
90 
96 
od 
a3 
a9 
ae 
b4 
ba 
bf 
c5 
ca 
cf 
d4 
d8 
dd 
e1 
e5 
eg 
ec 
ef 
f2 
£5 
£7 
£9 
fb 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
f8 
£6 


37 
3d 
42 
48 
Ad 
53 
59 
5£ 
65 
6b 
71 
78 
7e 
84 
8a 
91 
97 
od 
a3 
a9 
af 
b5 
ba 
cO 
c5 
ca 
cf 
d4 
dg 
dd 
e1 
e5 
e9 
ec 
ef 
f2 
£5 
£7 
£9 
fb 
fc 
fd 
fe 
ff 
ff 
ff 
ff 
fe 
fd 
fc 
fa 
f8 
£6 


38 
3d 
42 
48 
4e 
53 
59 
5f 
65 
6c 
72 
78 
7e 
85 
8b 
91 
97 
od 
a3 
a9 
af 
b5 
bb 
cO 
c5 
cb 
cf 
d4 
dg 
dd 
e1 
e5 
e9 
ec 
ef 
£2 
£5 
£7 
£9 
fb 
fc 
fd 
fe 
ff 
ff 
ff 
fe 
fe 
fd 
fb 
fa 
f8 
£6 


38 
3d 
43 
48 
4e 
54 
5a 
60 
66 
6c 
72 
78 
7£ 
85 
8b 
91 
98 
9e 
a4 
aa 
bO 
b5 
bb 
cO 
c6 
cb 
do 
d5 
dg 
dd 
e2 
e5 
e9 
ec 
f0 
f2 
£5 
£7 
£9 
fb 
fc 
fe 
fe 
ff 
ff 
ff 
fe 
fe 
fd 
fb 
fa 
f8 
£6 


38 
3e 
43 
49 
4e 
54 
5a 
60 
66 
6c 
73 
79 
7£ 
85 
8c 
92 
98 
9e 
a4 
aa 
bo 
b6 
bb 
c1 
c6 
cb 
do 
d5 
dg 
de 
e2 
e6 
e9 
ed 
f0 
£3 
£5 
£7 
£9 
fb 
fc 
fe 
fe 
ff 
ff 
ff 
fe 
fe 
fd 
fb 
fa 
f8 
£5 


480 
490 
4ad 
AbO 
4cO 
AdO 
4ed 
AfO 
500 
510 
520 
530 
540 
550 
560 
570 
580 
590 
5a 
5b0 
5cO 
5d0 
5e0 
5f£0 
600 
610 
620 
630 
640 
650 
660 
670 
680 
690 
6a0 
6b0 
6cO 
6d0 
6e0 
6£0 
700 
710 
720 
730 
740 
750 
760 
770 
780 
790 
7a0 
7b0 
7cO 


£5 
£2 
ef 
ec 
eg 
e5 
e1 
dd 
d8 
d4 
cf 
ca 
c5 
bf 
ba 
b4 
ae 
a9 
a3 
od 
96 
90 
8a 
84 
7e 
77 
71 
6b 
65 
5f 
59 
53 
Ad 
47 
42 
3c 
37 
32 
2d 
28 
24 
20 
1c 
18 
14 
11 


NWOoON OTT O 


£4 
£2 
ef 
ec 
eg 
e4 
e1 
dc 
d8 
d3 
cf 
ca 
c4 
b£ 
ba 
b4 
ae 
a8 
a2 
9c 
96 
90 
8a 
83 
7d 
77 
71 
6a 
64 
5e 
58 
52 
Ad 
47 
At 
3c 
37 
32 
2d 
28 
24 
1f 
1b 
18 
14 
11 


NWoOoON OT O 


£4 
f2 
ef 
eb 
e8 
e4 
e0 
dc 
ds 
d3 
ce 
c9 
c4 
bf 
b9 
b4 
ae 
a8 
a2 
9c 
96 
8£ 
89 
83 
7d 
77 
70 
6a 
64 
5e 
58 
52 
Ac 
47 
41 
3c 
36 
31 
2d 
28 
23 
1f 
1b 
17 
14 
11 


NWwWoON OT O 


£4 
£1 
ee 
eb 
eg 
e4 
e0 
dc 
d7 
d3 
ce 
c9 
c4 
be 
b9 
b3 
ad 
a7 
a2 
9b 
95 
8£ 
89 
83 
7C 
76 
70 
6a 
64 
5d 
58 
52 
Ac 
46 
41 
3b 
36 
31 
2c 
28 
23 
1f 
1b 
17 
14 
11 


NWOWO9O0T 0 
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NwWBPWOWOTAO 


NwWBOOMAS 


NwWBOOM AOS 


7d0 1 42444 4 4 4 4 4 4 4 4 4 424 4 2 
7e0 1 141 14 060 0 060 0 0 0 0 0 0 060 0 @ 
7£0 0 0 0 0 0 0 0 0 0 0 0 0 60 0 0 86 
--IMA.Boundary .273410538- - 


From forrerj@ucs.orst.edu Mon Jun 17 10:40:27 1996 
Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA17669 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
10:40:23 -0500 (CDT) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA28166; Mon, 17 Jun 1996 08:40:14 -0700 
Date: Mon, 17 Jun 1996 08:40:14 -0700 (PDT) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1218] BTL performance tests 
In-Reply-To: <H000029201ddaff£7@MHS> 
Message-Id: <Pine.OSF.3.91.960617083834 .20926A-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Robert, 

Congratulations! - Nice writeup. 

Is the program generally available yet, or what are your future plans. 
Keep up the good work. 


--Johan 


On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote: 


2b For clean wanted signal, 10-2 BER: 
Square pulse interferer 16dB 32dB 


> Hi all, 

> 

> Over the weekend I did a few performance tests on my PC- 
> Sound Blaster based DSP RTTY modem (BTL), and compared it 
> with my PK232MBX. Here's the results. Any coments welcome. 
> 

> PK232MBX BTL Ver 0.2 
> 

> 1 Noise performance: 15dB 12dB 

> Eb/No for BER=10‘%-2 

> 

> 2 Adjacent channel rejection (+500Hz 98 baud RTTY) 

> 

> 2a For 3dB rise in 10-2 Eb/No: 

> Square pulse interferer 9dB 30dB 

> Raised cosine pulse interferer 7 32dB 

> 

> 

> 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV OV 


Raised cosine pulse interferer - 35dB 


Observations: 


1. The BER taken includes errors due to both sync 
errors and data bit errors. For both modems 
relative contributions were about 50-50. 

If a bit synchronous mode were used rather than 
asynchronous baudot, BER would be half. My 
measurements show this is equivelent to a 1dB 
improvement in Eb/No for both modems. 


2. Two different interferer types were used. Both were 
phase continous FSK, 98 baud baudot, centred 500Hz 
above the wanted signal (wanted 1275/1445, interferer 
1775/1945) Standard RTTY has a square pulse shape 
resulting in high adjacent channel power. (-30dB @ 
500Hz) This limited measurements (and is a real on air 
limit too) However I tried shaping the interferering 
FSK pulses with raised cosine edges (shaped 64 of 82 
samples). ACP was reduced to -45dB @ 500Hz. Using this 
interferer, the true performance of the modem could be 
determined. This shaping reduced the interference RMS 
level to 72% and this was taken into account. 


The minimum signal level without intefernce was found 
to be 1 ADC step peak to peak, with dithering from the 
noise of almost 3 ADC steps peak-peak. (signals were 
calculated in 16 bits then quantised to 8 bits to allow 
noise dithering). At this level performance was still 
12dB Eb/No @ BER 104-2. This minimum signal level was 
44dB below the inteference level used above. Thus 
quantisation was not a limiting factor in the above 
measurements. Lower levels were possible but Eb/No was 
worsened and quantisation boundries became significant. 


Measurement Technique: 

1. Eb/No measurements 

Sampling rate was 8KHz 

The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
Space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
0.71 

The noise was generated by a 24bit maximum length PRN 
generator (poly=0x8D0000), doing 8 shifts per sample to get 


an 8 bit uniform random noise source. RMS to peak ratio of a 
uniform random noise source = 0.58 


> 


VV VVVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VM 


I have assumed a uniform distribution is OK since after 
bandpass filtering and integration the noise distribution 
aproaches gausian. (roughly speaking, the noise is averaged 
over the bit period, ie 178 samples, making the noise 
gausian by summation) 


For Eb/No calculations I have used the RMS levels at the 
8kHz sample rate. 


Peak-peak levels of signal=45 and noise=128 becomes 12db 
Eb/No thus: 


Eb/No = 20*log10 ((45/2 * 0.71) / (128/2 * 0.58)) 
+ 10*l0g10(4000 Hz) - 10*1l0g10(45 BPS) 


12.2 dB 


2. Adjacent channel measurements 
The signals are described above. 


The interferer baud rate of 98 baud was chosen to try to 
ovoid synchronisation between the wanted and interferer 
so errors would appear more random, hopefully giving a 
more accurate BER. However it does make the interferer 
wider, but pulse shaping dealt with that. This may not 
be the best method. 


Results are given for two different cases. 1. Fora 

3dB rise in the Eb/No required for 10-2 BER, and 

2. The interference level that gives a BER of 10%-2 
when the wanted signal is clean. These figures show 
respectivly the degradation in weak signal performance, 
and the maximum tolerable adjacent channel signal level 
when the wanted signal is clean. 


So, 12dB Eb/No doesn't sound all that hot, does it? But is this what 
should be expected for FSK without ECC? Eb/No would be 11dB if a bit 
synchronous mode was used. These are for a BER of 10%-2. 


Cheers, 


Rob 


From forrerj@ucs.orst.edu Mon Jun 17 11:09:42 1996 


Received: from ucs.orst.edu (forrerj@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA19201 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
11:09:39 -0500 (CDT) 
Received: by ucs.orst.edu; (5.65v3.2/1.1.8.2/13Mar96-1233PM) 

id AAQ6172; Mon, 17 Jun 1996 09:09:35 -0700 
Date: Mon, 17 Jun 1996 09:09:34 -0700 (PDT) 
From: Johan Forrer <forrerj@ucs.orst.edu> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1219] Re: Further thoughts on pulse shaping for HF 
In-Reply-To: <199606171016.DAAQ0188@unix.ka9q.ampr.org> 
Message-Id: <Pine.OSF.3.91.960617084032 .20926B-100000@ucs.orst.edu> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi Phil, 


On Mon, 17 Jun 1996, Phil Karn wrote: 
FYI, more about offset QPSK vs conventional QPSK. 


It looks as though the advantages of staggered (offset) QPSK are 
outweighted by the disadvantages, so I've switched to straight QPSK. 


There are two main advantages of offset QPSK: 1) less envelope droop 
when the signal is bandlimited, which turns into less sideband 
regrowth when the signal is nonlinearly amplified, and 2) less 
crosstalk between channels when the carrier phase reference is 
inaccurate. 


I originally chose SQPSK for reason #2; I don't really care too much 
about #1 since I am going to operate in a power-controlled regime 
where I assume there'll be a fair amount of transmit headroom most of 
the time, hence plenty of linearity. And even if there were sideband 
regrowth it wouldn't be as important a source of interference since 
I'm already operating at very low S/N ratios thanks to power control 
and coding. 


But it turns out that the crosstalk resistance of SQPSK is largely 
mitigated by greatly increased pattern-sensitive jitter in the carrier 
recovery system. In other words, although SQPSK has increased carrier 
phase jitter tolerance, it inherently increases the jitter of the 
recovered carrier which squanders the improved performance. 


I couldn't find a precise quantitative formulation for this, but from 
what I saw it looks like any gains SQPSK might have (especially at the 
very low Es/NOs I'm using) are small or even negative. And the last 
straw was that SQPSK is harder to implement than straight QPSK. So 
I've switched to straight QPSK. 


Phil 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


Your initial considerations for using the offset format seems quite valid 
if one perhaps can overcome the side effects you mention. 


About QPSK: The clean compact signal format that I see here is very 
encouraging. Using raised cosine pulse shaping is a bit of a hassle, but 
well worth it. I think if one can address the issue of non-linear 
amplification, that this may not be a bad way to go. 


One other thing that I experimented with this weekend was 

non-coherent detection of DQPSK. After getting it to work, I was quite 
surprized at how well it worked out. The constellations were tight 

and text-book style. There is the expected recovery loss (i.e. lower 
dynamic range) by giving up carrier extraction, however, I am of the 
opinion that in the end it may work out best for HF especially 

when used in conjunction with good coding. 


The issue about the use of an unmodulated carrier for doppler compensation: 
One of the first things that I do in my modem is to create an analytic 
signal, with a frequency shifter stage built into the front end. The 
frequency shifter is controlled by a doppler extractor algorithm. 

Doppler estimation is modelled as a second order AR process derived from 
the special unmodulated carrier after filtering by a narrow-band filter. 
The frequency estimate is obtained solving two simulataneous equations 
(Yule-Walker). There are provisions to deal with times when the carrier has 
faded - pretty much a very heavy damped system similar to what I do with 
clock extraction. 


Good luck with your project. 
--Johan 


From NOAOT@aol.com Mon Jun 17 13:03:12 1996 

Received: from emout09.mail.aol.com (emout09.mx.aol.com [198.81.11.24]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA24196 for <hfsig@tapr.org>; Mon, 17 Jun 
1996 13:03:07 -0500 (CDT) 

From: NOAOT@aol.com 

Received: by emout09.mail.aol.com (8.6.12/8.6.12) id O0AA10451; Mon, 17 Jun 1996 
14:02:57 -0400 

Date: Mon, 17 Jun 1996 14:02:57 -0400 

Message-ID: <960617140256_558017278@emout09.mail.aol.com> 

To: hfsig@tapr.org, Robert.Glassey@nmp.nokia.com 

Subject: Re: [HFSIG:1218] BTL performance tests 


Hi Bob-- 
In a message dated 96-06-17 06:48:58 EDT, you write: 
>Hi all, 


> 
>Over the weekend I did a few performance tests on my PC- 


>Sound Blaster based DSP RTTY modem (BTL), and compared it 
>with my PK232MBX. Here's the results. Any coments welcome. 
> 
> 


Very interesting weekend project you had there! I am not familiar with the 
BTL software you mentioned. Who is the author, and where is it available? Can 
the hardware interupt and io address of the sound card be changed so that it 
can be run on a notebook computer that has a "Sound Blaster compatible" 
chip? 


I have a Motorola DSP56002EVM board, and would like to run similar tests... 
--73's de Bob Carlson, nOaot@amsat.org 


From LANIER.R.A-@smtpgty.bwi.wec.com Mon Jun 17 14:06:24 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id OAA26860 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
14:06:12 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA31591; Mon, 17 Jun 1996 14:20:15 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1C5AC3F0; Mon, 17 Jun 96 15:04:31 
-0400 
Mime-Version: 1.0 
Date: Mon, 17 Jun 1996 14:56:48 -0400 
Message-Id: <1C5AC3F0.1858@smtpgty.bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1222] Re: BTL performance tests 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


Johan, 


I think you have me confused with someone else. I didn't write the 
text below - wish I did though. Its pretty impressive! 


73s de 
Tony, KE4ATO 


P.S. My first name is Robert, but I go by Tony (middle name Anthony) 
in all of my correspondence. 


ee ee ee ee eee Reply Separator 
Subject: [HFSIG:1222] Re: BTL performance tests 
Author: hfsig@tapr.org at BALT.SMTP 

Date: 6/17/96 10:49 AM 


Hi Robert, 

Congratulations! - Nice writeup. 

Is the program generally available yet, or what are your future plans. 
Keep up the good work. 


--Johan 


On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote: 

Hi all, 

Over the weekend I did a few performance tests on my PC- 

Sound Blaster based DSP RTTY modem (BTL), and compared it 

with my PK232MBX. Here's the results. Any coments welcome. 
PK232MBX BTL Ver 0.2 


1 Noise performance: 15dB 12dB 
Eb/No for BER=10%-2 


2 Adjacent channel rejection (+500Hz 98 baud RTTY) 
2a For 3dB rise in 104-2 Eb/No: 
Square pulse interferer 9dB 30dB 


Raised cosine pulse interferer - 32dB 


2b For clean wanted signal, 10-2 BER: 


Square pulse interferer 16dB 32dB 
Raised cosine pulse interferer - 35dB 
Observations: 


1. The BER taken includes errors due to both sync 
errors and data bit errors. For both modems 
relative contributions were about 50-50. 

If a bit synchronous mode were used rather than 
asynchronous baudot, BER would be half. My 
measurements show this is equivelent to a 1dB 
improvement in Eb/No for both modems. 


2. Two different interferer types were used. Both were 
phase continous FSK, 98 baud baudot, centred 500Hz 
above the wanted signal (wanted 1275/1445, interferer 
1775/1945) Standard RTTY has a square pulse shape 
resulting in high adjacent channel power. (-30dB @ 
500Hz) This limited measurements (and is a real on air 
limit too) However I tried shaping the interferering 


VV VVVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV WV 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV OV 


FSK pulses with raised cosine edges (shaped 64 of 82 
samples). ACP was reduced to -45dB @ 500Hz. Using this 
interferer, the true performance of the modem could be 
determined. This shaping reduced the interference RMS 
level to 72% and this was taken into account. 


The minimum signal level without intefernce was found 
to be 1 ADC step peak to peak, with dithering from the 
noise of almost 3 ADC steps peak-peak. (signals were 
calculated in 16 bits then quantised to 8 bits to allow 
noise dithering). At this level performance was still 
12dB Eb/No @ BER 104-2. This minimum signal level was 
44dB below the inteference level used above. Thus 
quantisation was not a limiting factor in the above 
measurements. Lower levels were possible but Eb/No was 
worsened and quantisation boundries became significant. 


Measurement Technique: 
1. Eb/No measurements 
Sampling rate was 8KHz 


The signal was 45 baud Baudot, phase continuous AFSK, 1275Hz 
Space and 1445Hz mark (170Hz shift). RMS to peak ratio = 
0.71 


The noise was generated by a 24bit maximum length PRN 
generator (poly=0x8D0000), doing 8 shifts per sample to get 
an 8 bit uniform random noise source. RMS to peak ratio of a 
uniform random noise source = 0.58 


I have assumed a uniform distribution is OK since after 
bandpass filtering and integration the noise distribution 
aproaches gausian. (roughly speaking, the noise is averaged 
over the bit period, ie 178 samples, making the noise 
gausian by summation) 


For Eb/No calculations I have used the RMS levels at the 
8kHz sample rate. 


Peak-peak levels of signal=45 and noise=128 becomes 12db 
Eb/No thus: 


Eb/No 


20*log10 ((45/2 * 0.71) / (128/2 * 0.58)) 
+ 10*l0g10(4000 Hz) - 10*l0g10(45 BPS) 
12.2 dB 


2. Adjacent channel measurements 


The signals are described above. 


The interferer baud rate of 98 baud was chosen to try to 
ovoid synchronisation between the wanted and interferer 
so errors would appear more random, hopefully giving a 
more accurate BER. However it does make the interferer 
wider, but pulse shaping dealt with that. This may not 
be the best method. 


Results are given for two different cases. 1. Fora 

3dB rise in the Eb/No required for 10-2 BER, and 

2. The interference level that gives a BER of 104-2 
when the wanted signal is clean. These figures show 
respectivly the degradation in weak signal performance, 
and the maximum tolerable adjacent channel signal level 
when the wanted signal is clean. 


So, 12dB Eb/No doesn't sound all that hot, does it? But is this what 
should be expected for FSK without ECC? Eb/No would be 11dB if a bit 
synchronous mode was used. These are for a BER of 10%-2. 


Cheers, 


Rob 
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From LANIER.R.A-@smtpgty.bwi.wec.com Mon Jun 17 16:22:47 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA03634 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
16:21:57 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA23940; Mon, 17 Jun 1996 16:36:09 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 1C5CC660; Mon, 17 Jun 96 17:21:42 
-0400 
Mime-Version: 1.0 
Date: Mon, 17 Jun 1996 17:19:52 -0400 
Message-Id: <1C5CC660.1858@smtpgty .bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1224] Re: BTL performance tests 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I am not the author of this software project! I don't know how my name 
got mixed up. 


Tony, KE4ATO 


tint Tayi ee Se sh eee eee Reply Separator 
Subject: [HFSIG:1224] Re: BTL performance tests 
Author: hfsig@tapr.org at BALT.SMTP 

Date: 6/17/96 1:15 PM 


Hi Bob-- 
In a message dated 96-06-17 06:48:58 EDT, you write: 


>Hi all, 

> 

>Over the weekend I did a few performance tests on my PC- 
>Sound Blaster based DSP RTTY modem (BTL), and compared it 
>with my PK232MBX. Here's the results. Any coments welcome. 
> 

> 


Very interesting weekend project you had there! I am not familiar with the 
BTL software you mentioned. Who is the author, and where is it available? Can 
the hardware interupt and io address of the sound card be changed so that it 
can be run on a notebook computer that has a "Sound Blaster compatible" 
chip? 


I have a Motorola DSP56002EVM board, and would like to run similar tests... 


--73's de Bob Carlson, nOaot@amsat.org 


From karn@qualcomm.com Mon Jun 17 22:37:52 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA17713 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
22:37:43 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
UAAO2588; Mon, 17 Jun 1996 20:37:10 -0700 (PDT) 

Date: Mon, 17 Jun 1996 20:37:10 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606180337 .UAAQ2588@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.OSF.3.91.960617084032 .20926B-100000@ucs.orst.edu> (message from 
Johan Forrer on Mon, 17 Jun 1996 11:22:58 -0500 (CDT)) 


Subject: Re: [HFSIG:1223] Re: Further thoughts on pulse shaping for HF 
Johan, 


Noncoherent schemes have a lot going for them on fading, dispersive 


channels. Not only because it's hard to extract a carrier phase 
that's rapidly changing, but also because the dynamic range of the 
fading tends to swamp the relatively small Eb/NO ratio differences 
between coherent and noncoherent modulation that are otherwise 
important on severely power-constrained nonfading AWGN channels. 


The three most important things on a fading channel are diversity, 
diversity and diversity. :-) Diversity can be in time, space or 
frequency. Coding helps promotes diversity, particularly in time by 
spreading out the influence of one data bit over many symbols (only 
some of which may get through). And even QPSK can help by simply 
creating more slots for those coded symbols in the first place. 


Phil 


From karn@qualcomm.com Mon Jun 17 22:58:10 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id WAA18215 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
22:58:07 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
UAAO2630; Mon, 17 Jun 1996 20:57:35 -0700 (PDT) 

Date: Mon, 17 Jun 1996 20:57:35 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606180357 .UAAQ2630@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <Pine.OSF.3.91.960617084032.20926B-100000@ucs.orst.edu> (message from 
Johan Forrer on Mon, 17 Jun 1996 11:22:58 -0500 (CDT)) 

Subject: Re: [HFSIG:1223] Re: Further thoughts on pulse shaping for HF 


>One of the first things that I do in my modem is to create an analytic 
>signal, with a frequency shifter stage built into the front end. The 
>frequency shifter is controlled by a doppler extractor algorithm. 


This is exactly my approach also. The frequency shifter is at present 
set to a fixed value based on the estimated frequency of the carrier 
burst in the packet preamble. This assumes that any residual error is 
small compared to the data rate (it is), so it can be tracked out 
after filtering and downsampling from 8x to 1x the symbol rate. (The 
downsampling starts once I have obtained one-shot symbol sync from the 
preamble). 


Although all further processing has to be done with complex 
arithmetic, performance-wise I think I'm still ahead after the 
downsampling. 


Eventually I will probably have to add a doppler chirper to the 
frequency shifter driven by an orbit tracking routine. This is 
relatively straightforward given accurate orbital elements, time and 
station location. 


Phil 


From forrerj@ucs.orst.edu Mon Jun 17 23:54:01 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAA21367 for <hfsig@tapr.org>; Mon, 17 Jun 1996 
23:53:53 -0500 (CDT) 
Received: from p08.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA18775; Mon, 17 Jun 1996 21:53:44 -0700 
Message-Id: <1.5.4.16.19960618055458.4c9f67fc@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Mon, 17 Jun 1996 21:54:58 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1225] Re: BTL performance tests 


At 02:21 PM 6/17/96 -0500, you wrote: 
Johan, 


I think you have me confused with someone else. I didn't write the 
text below - wish I did though. Its pretty impressive! 


73s de 
Tony, KE4ATO 


P.S. My first name is Robert, but I go by Tony (middle name Anthony) 
in all of my correspondence. 


VVVVV VV VV VV WV 


Strange things do happen :-) 


My reply was directed at Robert (Rob) Glassey's fine work (please see below) 
- somehow we got our lines crossed - no harm done. Still a nice piece of 
work Rob. 


--Johan 


>Hi Robert, 

> 

>Congratulations! - Nice writeup. 

> 

>Is the program generally available yet, or what are your future plans. 
> 

>Keep up the good work. 


eran some lines deleted 


>On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote: 


Sacer ash some more lines deleted 


From Robert.Glassey@nmp.nokia.com Tue Jun 18 04:22:31 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAAQ3763 for <hfsig@tapr.org>; Tue, 18 Jun 1996 
04:22:27 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA27649 for <hfsig@tapr.org>; Tue, 
18 Jun 1996 12:21:49 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA262409595; Tue, 18 Jun 1996 12:19:55 +0300 
X-Openmail-Hops: 2 
Date: Tue, 18 Jun 96 10:15:50 +0100 
Message-Id: <H000029201df£c18f£@MHS> 
In-Reply-To: <Pine.OSF.3.91.960617083834.20926A-100000@ucs.orst.edu> 
Subject: [HFSIG:1222] Re: BTL performance tests 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


> Over the weekend I did a few performance tests on my PC- 
> Sound Blaster based DSP RTTY modem (BTL), and compared it 
> with my PK232MBX. Here's the results. Any coments welcome. 


> Hi Robert, 

> 

> Congratulations! - Nice writeup. 

> 

> Is the program generally available yet, or what are your future plans. 
> 

> Keep up the good work. 

> 

> --Johan 

> 

> 

> On Mon, 17 Jun 1996 Robert.Glassey@nmp.nokia.com wrote: 
> 

> > Hi all, 

>> 

> 

> 

> 


Thanks, Its still on beta test, with VO.2beta out very soon (I hope) 
- Sorry to those testers still waiting for the next version, 
unfortunatly my weekend projects don't always get the time they deserve. 


The release version 1.0, should be ready in a copule of weeks. This 
version recieves standard baudot only, with variable baud, shift and 
centre frequency, plus a few other features. 


My next release (could be 6 months away) will have TX, and a wide shift 
mode for comercial news services etc. I hope to include AMTOR FEC and 
ARQ modes as well. Plus any improvements in performance I can find, 


probably a bit-synchronous demod mode (for standard 7.5 bit baudot), and 
maybe an improved tuning indicator, auto tuning, and mode/baud 
detection. 


This was my intention from the start for a first release, but things 
have taken a while, and I think people want it as it is right now. 


Ultimatly I would like to use BTL as a platform for more complex modes 
such as PACTOR II or Clover II or other multicarrier modes that may be 
developed through HFSIG. I'm also keen to implement very low SNR modes, 
such as DBPSK with heaps of ECC using a type II hybrid ARQ protocol. 


I intend to release up to version 2 as public domain freeware. 


Cheers, 
Rob Glassey, GOVTQ 


From BRYD@KIDD.CO.ZA Tue Jun 18 04:26:46 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAAQ4022 for <hfsig@tapr.org>; Tue, 18 Jun 1996 
04:26:41 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuVx3H-OOOPAWC; Tue, 18 Jun 96 11:26 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Tue, 18 Jun 1996 11:33:08 +0200 
Message-Id: <s1c693£3.043@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Tue, 18 Jun 1996 11:26:45 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: Well, the standard Intel programmer's references are pretty 


good. They tell you all you really need 


Well, the standard Intel programmer's references are pretty good. They tell you 
all you really need to know to 

optimize DSP code on the 

Pentium, such as instruction clock counts and considerations on how to keep the 
pipelines full. 


Phil 
I see. Thanks. 73 danie 


From Robert.Glassey@nmp.nokia.com Tue Jun 18 05:38:14 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id FAAQ5769 for <hfsig@tapr.org>; Tue, 18 Jun 1996 
05:38:11 -0500 (CDT) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA29755 for <hfsig@tapr.org>; Tue, 


18 Jun 1996 12:52:02 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.16/16.2) id AA298861408; Tue, 18 Jun 1996 12:50:08 +0300 
X-Openmail-Hops: 2 
Date: Tue, 18 Jun 96 10:45:45 +0100 
Message-Id: <H000029201dfdd45@MHS> 
In-Reply-To: <960617140256_558017278@emout09.mail.aol.com> 
Subject: [HFSIG:1224] Re: BTL performance tests 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


Hi Bob-- 
In a message dated 96-06-17 06:48:58 EDT, you write: 


>Hi all, 

> 

>Over the weekend I did a few performance tests on my PC- 
>Sound Blaster based DSP RTTY modem (BTL), and compared it 
>with my PK232MBX. Here's the results. Any coments welcome. 
> 

> 


Very interesting weekend project you had there! I am not familiar 
with the BTL software you mentioned. Who is the author, and where is 
it available? Can the hardware interupt and io address of the sound 
card be changed so that it can be run on a notebook computer that has 
a "Sound Blaster compatible" chip? 


I have a Motorola DSP56002EVM board, and would like to run similar 
tests... 


VV VV VV VV VV VV VV VV VV VV VV 


--73's de Bob Carlson, nOaot@amsat.org 
Hi Bob, 


BTL is not on general release yet, but soon will be. BTL is my '‘baby' 
and has taken me since around August last year to write (very slowly 
since its a weekend project). When released, I hope to get it onto an 
FTP site somewhere, maybe the TAPR site? This version is FREE! 


Soundblaster parameters are user configurable, and it accepts the 
standard sound blaster enviroment variable BLASTER=.... 


It should work on any soundblaster compatible from the original v1.0 to 
the latest AWE32. 


It should run on your notebook if its fast enough. To date, the slowest 
machine I've tried is a 486sx25 and that works fine. If speed is a 
problem I may release a cut down 1.5 version which should run faster. 


The tests were done with a C program that generated test signals plus 
noise that I used as my signal generator for the tests. 


The test signal was played on the SB for the PK 232, and taken directly 
from disk, in real time, for the BTL tests, by substituting the 
soundblaster DMA for a double buffered disk routine. 


I also have a DAT recorder that I have used in the past for testing. 
I'll have to repeat these BTL tests using recorded signals. 


Cheers, 
Rob, GOVTQ 


From BRYD@KIDD.CO.ZA Wed Jun 19 08:46:09 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id IAAQ9757 for <hfsig@tapr.org>; Wed, 19 Jun 1996 
08:46:04 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuWNsX-OOOPHOC; Wed, 19 Jun 96 16:05 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Wed, 19 Jun 1996 15:52:34 +0200 
Message-Id: <s1c82242.070@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Wed, 19 Jun 1996 15:46:16 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: 


I also have a DAT recorder that I have used in the past for testing. 
I'll have to repeat these BTL tests using recorded signals. 


Bob how well does the DAT recorder work and is it not too expensive ? I also have 
a need for soemthing like that. 

It is difficult with the sat signals as they pass very quickly...no time to 
recompile and download hi :-) 


danie zs6awk 


From Robert.Glassey@nmp.nokia.com Wed Jun 19 10:34:23 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA16025 for <hfsig@tapr.org>; Wed, 19 Jun 1996 
10:34:15 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id SAA26250 for <hfsig@tapr.org>; Wed, 
19 Jun 1996 18:33:35 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA104938299; Wed, 19 Jun 1996 18:31:39 +0300 
X-Openmail-Hops: 2 
Date: Wed, 19 Jun 96 16:30:26 +0100 
Message-Id: <H000029201e2ac42@MHS> 


In-Reply-To: <s1c82242.070@KIDD.CO.ZA> 
Subject: [HFSIG:1233] 

Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


>> I also have a DAT recorder that I have used in the past for testing. 
>> Bob how well does the DAT recorder work and is it not too expensive ? 
> I also have a need for soemthing like that. 

> It is difficult with the sat signals as they pass very quickly...no 

> time to recompile and download hi :-) 

> 

> danie zs6awk 


Hi Danie, 


They work very well, even preserve timing on amtor/pactor. They are a 
little pricy, mine cost around $650 US, but it is a walkman model, (Sony 
TCD-D7). A hi-fi component style version should be cheaper. I find the 
walkman handy for taking a known test signal from one PC to another for 
testing on different sound cards etc. They are also usefull for 
recording a live QSO then replaying it over and over while modifying the 
program to test with a known signal. They are also available second hand 
occasionally, but beware of older models, reliability was a problem with 
them, and they're probably on their last legs now if they haven't 
already died. 


If you have a sound blaster your best bet (and cheapest) would be to 
record the satilite on disk the play it back to the DSP. 10 minutes will 
take about 5MB. You may need make your DSP code more independent of the 
PC (buffer output etc) or get another PC! 


Its actually quite simple to write a C program to play the sound file 
and act as a dumb terminal at the same time. 


73's 
Rob, 
GOVTQ 


From forrerj@ucs.orst.edu Wed Jun 19 11:17:09 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA17643 for <hfsig@tapr.org>; Wed, 19 Jun 1996 
11:17:06 -0500 (CDT) 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA19123; Wed, 19 Jun 1996 09:16:55 -0700 
Message-Id: <1.5.4.16.19960619171812.3f8ffe56@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 19 Jun 1996 09:18:12 -0800 


To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1228] Re: Further thoughts on pulse shaping for HF 


Phil, 


>Although all further processing has to be done with complex 
>arithmetic, performance-wise I think I'm still ahead after the 
>downsampling. 

> 

>Eventually I will probably have to add a doppler chirper to the 
>frequency shifter driven by an orbit tracking routine. This is 
>relatively straightforward given accurate orbital elements, time and 
>station location. 


Sounds quite involved - fortunate that you have such a nice closed-form 
predition method. I was wondering; are there any residual effects to deal 
with due to spin motion of the satellite? some higher than doppler phasing 
effects or does the circular polarized antennas take care of it? 


Re: Doppler tracking on HF: 

I'm looking into following reasonably fast-changing doppler effects, i.e., a 
fraction of a symbol time. The method that I'm interested in for estimating 
doppler comes from LPC methodology and the ideas are well developed - 
extracting pitch, or in other words specifying a filter from the signal. I'm 
not sure how well it will work for what I am doing, but I'm willing to give 
it a chance. 


Anyway, the modem will have to go on the back burner for a while - something 
else has come up that needs to be done. 


--Johan 


From forrerj@ucs.orst.edu Wed Jun 19 11:17:09 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA17644 for <hfsig@tapr.org>; Wed, 19 Jun 1996 
11:17:06 -0500 (CDT) 
Received: from p00.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AAQ8169; Wed, 19 Jun 1996 09:17:00 -0700 
Message-Id: <1.5.4.16.19960619171816.0d271abO0@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 19 Jun 1996 09:18:16 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1230] Re: BTL performance tests 


Hi Rob, 


>Ultimatly I would like to use BTL as a platform for more complex modes 
>such as PACTOR II or Clover II or other multicarrier modes that may be 
>developed through HFSIG. I'm also keen to implement very low SNR modes, 
>such as DBPSK with heaps of ECC using a type II hybrid ARQ protocol. 

> 

>I intend to release up to version 2 as public domain freeware. 

> 

> 

>Cheers, 

> 

>Rob Glassey, GOVTQ 

> 

> 


Excellent! 


Would you consider uploading a program version to HFSIG? If you do, also 
please provide a ".txt" version for the folks that browse the files with 
their web browser. 


Keep us posted on your progress - sounds like good stuff. 
--Johan 


From karn@qualcomm.com Wed Jun 19 18:27:25 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id SAAQ6837 for <hfsig@tapr.org>; Wed, 19 Jun 1996 
18:27:22 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA23790; Wed, 19 Jun 1996 16:26:49 -0700 (PDT) 

Date: Wed, 19 Jun 1996 16:26:49 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199606192326.QAA23790@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.16.19960619171812 .3£8ffe56@ucs.orst.edu> (message from Johan 
Forrer on Wed, 19 Jun 1996 11:21:34 -0500 (CDT)) 

Subject: Re: [HFSIG:1235] Re: Further thoughts on pulse shaping for HF 


>Sounds quite involved - fortunate that you have such a nice closed-form 
>predition method. I was wondering; are there any residual effects to deal 
>with due to spin motion of the satellite? some higher than doppler phasing 
>effects or does the circular polarized antennas take care of it? 


As a matter of fact, yes. James Miller has pointed out that the S-band 
antenna on AO-13 is not mounted along the center of mass, so if the 
antennas are not lined up on earth the antenna moves to and fro along 
the line of sight as the spacecraft spins. This introduces a 
Sinusoidal doppler shift on the order of 5 Hz, which is significant to 
me. 


Of course, this may be somewhat academic as I probably won't get this 
stuff on mode S before AO-13 burns up, and P3D is 3-axis stabilized. 


Phil 


From BRYD@KIDD.CO.ZA Thu Jun 20 06:29:12 1996 
Received: from igw01 (igw01.kidd.co.za [192.96.246.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA11730 for <hfsig@tapr.org>; Thu, 20 Jun 1996 
06:29:02 -0500 (CDT) 
Received: from KIDD.CO.ZA by igw01 with smtp 
(Smail3.1.29.1 #3) id mOuWhvO-OOOPLoC; Thu, 20 Jun 96 13:28 GMT+0200 
Received: from KenMail-Message_Server by KIDD.CO.ZA 
with Novell_GroupWise; Thu, 20 Jun 1996 13:35:46 +0200 
Message-Id: <s1c953b2.040@KIDD.CO.ZA> 
X-Mailer: Novell GroupWise 4.1 
Date: Thu, 20 Jun 1996 13:28:28 +0200 
From: Danie Brynard <BRYD@KIDD.CO.ZA> 
To: hfsig@tapr.org 
Subject: 


If you have a sound blaster your best bet (and cheapest) would be to record the 
satilite on disk the play it back to 

the DSP. 10 minutes will take about 5MB. You may need make your DSP code more 
independent of the 

PC (buffer output etc) or get another PC! 


Its actually quite simple to write a C program to play the sound file and act as a 
dumb terminal at the same time. 


I see. Yes I do have another PC. BTW what is the bandwidth of the DAT tape ? I 
suppose it has now phase 
distorsion ie wow & flutter ? 


danie 


From LANIER.R.A-@smtpgty.bwi.wec.com Thu Jun 20 10:41:54 1996 
Received: from tron.bwi.wec.com (tron.bwi.wec.com [129.228.4.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA20149 for <hfsig@tapr.org>; Thu, 20 Jun 1996 
10:41:49 -0500 (CDT) 
Received: from smtpgty.bwi.wec.com by tron. bwi.wec.com; 
(5.65/1.1.8.2/31May95-0229PM) 
id AA22177; Thu, 20 Jun 1996 11:27:48 -0400 

Received: from ccMail by smtpgty.bwi.wec.com 

(IMA Internet Exchange 2.0 Enterprise) id 10971760; Thu, 20 Jun 96 11:42:46 
-0400 
Mime-Version: 1.0 
Date: Thu, 20 Jun 1996 11:37:50 -0400 
Message-Id: <1C971760.1858@smtpgty .bwi.wec.com> 
From: LANIER.R.A-@smtpgty.bwi.wec.com (LANIER.R.A-) 
Subject: Re: [HFSIG:1238] 


To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I'm curious, what would this C program look like? 


73s de 
Tony, KE4ATO 


Subject: [HFSIG:1238] 
Author: hfsig@tapr.org at BALT.SMTP 
Date: 6/20/96 6:36 AM 


If you have a sound blaster your best bet (and cheapest) would be to record the 
satilite on disk the play it back to 

the DSP. 10 minutes will take about 5MB. You may need make your DSP code more 
independent of the 

PC (buffer output etc) or get another PC! 


Its actually quite simple to write a C program to play the sound file and act as 
a dumb terminal at the same time. 


I see. Yes I do have another PC. BTW what is the bandwidth of the DAT tape ? I 
suppose it has now phase 
distorsion ie wow & flutter ? 


danie 


From Robert.Glassey@nmp.nokia.com Thu Jun 20 12:40:16 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA24162 for <hfsig@tapr.org>; Thu, 20 Jun 1996 
12:40:12 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA10748; Thu, 20 Jun 1996 20:39:36 
+0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA297632257; Thu, 20 Jun 1996 20:37:37 +0300 
X-Openmail-Hops: 2 
Date: Thu, 20 Jun 96 18:36:59 +0100 
Message-Id: <H000029201e4bf8e@MHS> 
In-Reply-To: <1C971760.1858@smtpgty.bwi.wec.com> 
Subject: [HFSIG:1239] Re: 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org, LANIER.R.A-@smtpgty.bwi.wec.com 


>> Its actually quite simple to write a C program to play the sound file 
>> and act as a dumb terminal at the same time. 


I'm curious, what would this C program look like? 


73s de 
Tony, KE4ATO 


VVV NV 


There's libraries available on simtel for the SB stuff. It would look 
something like this: 


main () 


¢ 
soundblaster_reset(); /* also checks for card x/ 
buffer_mem=faralloc(128«10241); /*x 64 k buffer when page aligned x/ 


buffer=[page alignment of buffer_mem pointer ie to get XX00:0000] 
/x this is so the DMA doesn't cross a 64K page boundry x/ 


[setup interupt on SB IRQ] 

[set DMA parameters - port commands] 

[set sound blaster sample rate -port commands] 
file=fopen("sat_rec","rb"); 

[read 32k from file into buffer] 

[start SB playing in auto init mode] 


quit=0; 
buffer_flag=0; 
while(! quit) 
q 
/x double buffered disk read for SB x/ 
dma=[read DMA pointer] 
if (dma > 16384) && (buffer_flag==0) 
q 
/x if was lo and now playing hi half, load new low halfx/ 
[read next 16k to low half of buffer]; buffer_flag=1; 
$ 
if (dma < 16384) && (buffer_flag==1) 
- 
/x if was hi and now playing lo half, load new high halfx/ 
[read next 16k to high half of buffer]; buffer_flag=0; 
$ 


/* very dumb terminal x/ 
if(kbhit()) 
{ 


ch=getch(); 
if(ch==27) quit=1; /* esc quits x/ 
[ output ch to com port ] 
$ 
[if char available at com port] putc(ch); 


$ 


stop_sb(); 
remove_sb_interupt(); 
fclose(file) 
farfree(buffer_mem) 


$ 


sb_interupt() 

q 

[acknoledge SB interupt - sb port commands] 
out 20h,20h 

$ 


I'm bound to have forgotten something, and have brushed over many things 
but this is roughly how it would look. There's lots of other error and 
end of file stuff as well. 


To record the sample there's a few simple but good programs on simtel 
which will do the trick nicely. Actually there might even be a 
background TSR program that will play the soundfile in the background so 


you can just run your normal terminal program. Or maybe use a standard 
windows player and terminal, that might be even easier! 


Cheers, 
Rob 


From zs6awk@global.co.za Thu Jun 20 15:03:14 1996 

Received: from linO01.global.co.za (linO01.global.co.za [196.3.164.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA29685 for <hfsig@tapr.org>; Thu, 20 Jun 1996 
15:03:09 -0500 (CDT) 

Received: from anx_116.global.co.za (anx_82.global.co.za [196.3.164.132]) by 
lin01.global.co.za (8.7.3/8.7.3) with SMTP id WAA06699 for <hfsig@tapr.org>; Thu, 
20 Jun 1996 22:01:01 -0200 (GMT) 

Message-Id: <199606210001.WAA06699@1in01. global.co.za> 

X-Sender: zs6awk@mail.global.co.za 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 20 Jun 1996 22:02:32 +0200 

To: hfsig@tapr.org 

From: zs6awk@global.co.za (Danie Brynard) 

Subject: info on C31 DSK ? 


Does anybody have more info on the new TI TMS320C31 DSK ? Like amount of RAM 
and release date ? How good is the debugger ie compared to say 56002 OnCE ? 


danie zs6awk 


From Robert.Glassey@nmp.nokia.com Fri Jun 21 08:59:52 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id IAA11919 for <hfsig@tapr.org>; Fri, 21 Jun 1996 
08:59:49 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id QAA22122 for <hfsig@tapr.org>; Fri, 
21 Jun 1996 16:59:15 +0300 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA098535435; Fri, 21 Jun 1996 16:57:15 +0300 
X-Openmail-Hops: 2 
Date: Fri, 21 Jun 96 14:56:54 +0100 
Message-Id: <H000029201e58799@MHS> 
In-Reply-To: <1C9943C0.1858@smtpsty.bwi.wec.com> 
Subject: Re: [HFSIG:1239] Re: 
Mime-Version: 1.0 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=ISO-8859-1; name="Re:" 
Content-Transfer-Encoding: 7bit 


Thanks for the code Rob, I appreciate it. Can this code be 
compiled under Linux using GCC+? 


VVV NV 


Tony, KE4ATO 

Of course its only pseduo code, but it is intended for a PC under DOS. 
Under Linux, you'd be better off using the sound card drivers that 
already exist for Linux. Sorry I don't know very much about these, only 
that they exist. 

PS. I've just notices an error in my pseudo code, I allocated a 64 
buffer then only used 32K of it (16K for each half of the bouble buffer) 
You only really needed to allocate 32K thus: 
buffer_mem=faralloc(64*10241); /* 32 k buffer when page aligned x/ 


buffer=[page alignment of buffer_mem pointer ie to get XX00:0000] 
/x this is so the DMA doesn't cross a 64K page boundry x/ 


This defines a page aligned 32K buffer in an alocated block of 64K. 


It would have worked before, it just allocated twice as much memory as 
required. 


Cheers, 
Rob 


From forrerj@ucs.orst.edu Thu Jun 27 11:30:11 1996 


Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ5111 for <HFSIG@TAPR.ORG>; Thu, 27 Jun 1996 
11:30:10 -0500 (CDT) 
Received: from p04.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA27122; Thu, 27 Jun 1996 09:30:02 -0700 
Message-Id: <1.5.4.16.19960627173228 .344f05c6@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu (Unverified) 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 27 Jun 1996 09:32:28 -0800 
To: HFSIG@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Question on orthoganal tone spacing 


Hi folks, 
HFSIG been quiet lately? 
I have a question that I would appreciate some insight - I'm a bit confused. 


My multi-channel modulation scheme uses four parallel tones, each modulated 
at a rate of 75 symbols per second (bauds). If I understood our earlier 
discussion, each tone should fit into a 2*75=150 Hz slot. Why does this not 
follow the orthogonal 1/T rule for orthogonal spacing, that would put tones 
at 75 Hz spacing, not 150 as above? 


To check this out, I looked at the MIL-STD-188 16-tone specifications which 
is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing 
but experience a substantial amount of inter-channel interference. 
Demodulation still works but with a serious performance hit - the recovered 
channel constellations are really smeared. However, when I go to the 150 
(i.e. 2*T) spacing - the constallations are text-book quality. 


So - what am I missing ? 


A little more of where this is heading: four 75 baud tones with DQPSK 
modulation gives 600 bps. Various forms of diversity is possible. The 
highest form of diversity is when each channel carries the same information 
in DBPSK, in which case the rate is only 75 bps, but at four times diversity. 


It would be possible to do what the Pactor-II folks do and up the DQPSK 
(4-DPSK) to 8-DQPSK that would essentially yield 1200 bps. Again, it is 
possible to use various forms of diversity. For example, using 8-DQPSK, and 
a factor of two diversity, would yield 600 bps. 


The idea is to use an interleaved convolutional code, something along the 
lines that Phil have been working on. The waveform is 600 Hz wide at the -50 
dB level, and could possibly be squeezed be into the 500 Hz constraint. 
However, I do not recommend folks getting ideas of using narrow crystal 


filters - severe phase distortion at the filter edges. 


If time allows, I hope to do a show and tell demo of the project at the 
HFSIG meeting during the upcoming DCC (September 20-22, Seattle). 


I sincerely hope that this effort will lead to a future open-architecture 
HF-digital protocol. All specifications will be freely available for those 
to implement it. Commercial implementations would be encouraged and I would 
be happy to offer consulting services if anyone is interested. HFSIG is 
there to encourage development and exchange ideas. 


--Johan, KC7WW 


From forrerj@ucs.orst.edu Thu Jun 27 13:55:36 1996 
Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA11266 for <HFSIG@TAPR.ORG>; Thu, 27 Jun 1996 
13:55:33 -0500 (CDT) 
Received: from p02.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 
id AA23538; Thu, 27 Jun 1996 11:55:25 -0700 
Message-Id: <1.5.4.16.19960627195749. Od3£5f2c@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 27 Jun 1996 11:57:49 -0800 
To: HFSIG@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Help communicate/translate in Italian 


Hi, 
Is there a kind soul out there that can help us communicate with a very keen 


and interested Italian gentleman? 


I have been contacted several times by this keen individual, and although I 
can help myself in several languages, Italian unfortunately is not one of 
them - I hate to dissapoint, but I need a bit more than a few hand-waving 
gestures explaining how to get started using a DSP modem. 


The gentleman is located in Milan. Any help would be greatly appreciated. 

Thanks a lot. 

--Johan 

From bm@lynx.ve3jf.ampr.org Fri Jun 28 10:30:07 1996 

Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA29585 for <hfsig@tapr.org>; Fri, 28 Jun 


1996 10:30:00 -0500 (CDT) 
Received: (from bm@localhost) by lynx.ve3jf£.ampr.org (8.6.12/8.6.12) id PAA01611 


for hfsig@tapr.org; Fri, 28 Jun 1996 15:31:17 GMT 

From: Barry McLarnon VE3JF <bm@lynx.ve3jf£.ampr.org> 

Message-Id: <199606281531.PAA01611@lynx.ve3j£.ampr.org> 

Subject: Re: [HFSIG:1243] Question on orthoganal tone spacing 

To: hfsig@tapr.org 

Date: Fri, 28 Jun 1996 15:31:17 +0000 (GMT) 

In-Reply-To: <1.5.4.16.19960627173228 .344f05c6@ucs.orst.edu> from "Johan Forrer" 
at Jun 27, 96 11:31:51 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 


I have a question that I would appreciate some insight - I'm a bit confused. 


> 

> 

> My multi-channel modulation scheme uses four parallel tones, each modulated 
> at a rate of 75 symbols per second (bauds). If I understood our earlier 

> discussion, each tone should fit into a 2*75=150 Hz slot. Why does this not 
> follow the orthogonal 1/T rule for orthogonal spacing, that would put tones 
> at 75 Hz spacing, not 150 as above? 


The 1/T rule does apply here - it *xshould* work with 75 Hz spacing. 


To check this out, I looked at the MIL-STD-188 16-tone specifications which 
is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing 
but experience a substantial amount of inter-channel interference. 
Demodulation still works but with a serious performance hit - the recovered 
channel constellations are really smeared. However, when I go to the 150 
(i.e. 2*T) spacing - the constallations are text-book quality. 


VV VV VV VV 


So - what am I missing ? 


In the case of MIL-STD-188, there is a "guard interval" of about 4.2 ms 
at the beginning of the 13.3 ms symbol interval to reduce ISI caused 

by multipath. The integrate-and-dump (or equivalent) doesn't start 
until after the guard interval, so T = 9.1 ms and 1/T = 110 Hz. 


If your scheme isn't working at 1/T spacing, it seems like an 
implementation issue. Perhaps you're using some kind of baseband pulse 
shaping which is destroying the orthogonality of the tones at minimum 
Spacing? 


Barry 
Barry McLarnon VE3JF/VA3TCP | Internet: bm@hydra.carleton.ca 
Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3jf£.ampr.org 
Packet Working Group | Web: http: //hydra.carleton.ca 


From forrerj@ucs.orst.edu Fri Jun 28 22:30:35 1996 

Received: from ucs.orst.edu (root@UCS.ORST.EDU [128.193.4.5]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id WAA28033 for <hfsig@tapr.org>; Fri, 28 Jun 1996 
22:30:31 -0500 (CDT) 

Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.2/1.1.8.2/13Mar96-1233PM) 


id AA11728; Fri, 28 Jun 1996 20:30:24 -0700 
Message-Id: <1.5.4.16.19960629043259 .3667fa2c@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu (Unverified) 
X-Mailer: Windows Eudora Light Version 1.5.4 (16) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 28 Jun 1996 20:32:59 -0800 
To: hfsig@tapr.org 
From: Johan Forrer <forrerj@ucs.orst.edu> 
Subject: Re: [HFSIG:1245] Re: Question on orthoganal tone spacing 


Hi Barry, 


> 

>The 1/T rule does apply here - it *should* work with 75 Hz spacing. 

> 

>> To check this out, I looked at the MIL-STD-188 16-tone specifications which 
>> is quite similar, i.e., 75 baud with 110 Hz spacing. I tried this spacing 
>> but experience a substantial amount of inter-channel interference. 

>> Demodulation still works but with a serious performance hit - the recovered 
>> channel constellations are really smeared. However, when I go to the 150 

>> (i.e. 2*T) spacing - the constallations are text-book quality. 


>> So - what am I missing ? 


>In the case of MIL-STD-188, there is a "guard interval" of about 4.2 ms 
>at the beginning of the 13.3 ms symbol interval to reduce ISI caused 
>by multipath. The integrate-and-dump (or equivalent) doesn't start 
>until after the guard interval, so T = 9.1 ms and 1/T = 110 Hz. 

> 

>If your scheme isn't working at 1/T spacing, it seems like an 
>implementation issue. Perhaps you're using some kind of baseband pulse 
>shaping which is destroying the orthogonality of the tones at minimum 


>spacing? 

> 

>Barry 

> 

>-- 

> Barry McLarnon VE3JF/VA3TCP | Internet: bm@hydra.carleton.ca 

> Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3j£.ampr.org 

> Packet Working Group | Web: http://hydra.carleton.ca 
> 

> 


Thanks for the response - you make a good point. It may well be an 
implementation issue as there are many factors involved. 


So ... I did a bit of research to understand things a bit better: 
I created a signal like the MIL-STD-188 16-tone. 


The way that this is done is to modulate all the carriers, sum them in one 
signal and then time-domain filter the ensamble using a pulse shape that has 


a "rounded" edges. The edges of this pulse shape are made up of 1/2 Hamming 
rolloff cones that has a duration, the length of the guard zone (2.12 ms). 
The main portion of the pulse top then is at unity. 


The resultant signal audibly sounds reasonable, none of those ugly clicking 
noises, a kind of a warbling-buzzing sound. My spectrum analyzer showed the 
carriers are contained as expected and the noise floor is some 30-40 dB down 
from the tone carriers. 


Result: yes, indeed, the demodulator demodulates the individual signals OK, 
but the recovered constellations are *not*x as clean as what I would like to 
see. Maybe some more implementation issues that may make some improvement? 


I compared this to my individually-RC pulse-shaped signal waveform. Note 
that here I use 2%xT channel spacing, which is just slighty more than the 
MIL-STD-188 tone spacing 

(450 vs 440 Hz). I noted significant differences; The dynamic range between 
constellation points are at least an order of magnitude better, and the 
spurious levels in the spectrum are at least twice a low. 


Thus I suspect that the RC pulse shaping has brought about a cleaner 
emission and also improved the eye opening substantially. I would be as 
brave as to say that I have high hopes that the scheme may be usable at 8-DQPSK. 


OK so where does this leave us with the issue of orthogonality? 


I do suspect that it may be practically impossible to achieve that, i.e., 
having that accuracy between the tone set. It seem to take only a very small 
error to distroy the orthogonality to the point where it becomes nearly 
useless. This may be why the MIL-STD-188 set also does not use the 1/T 
Spacing?. From your description above, the effectively space the tones is 
110 Hz spacing (based on the 9.09 ms pulse). So we are already removed from 
the 1/T orthogonal spacing. 


Long story, thanks for your patience, but thought it was worth looking into. 
73's 
--Johan 


From karn@baa01075.slip.digex.net Sat Jun 29 01:32:17 1996 

Received: from baa01075.slip.digex.net (root@baa01075.slip.digex.net 
[204.91.208.66]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA11832 for 
<hfsig@tapr.org>; Sat, 29 Jun 1996 01:32:09 -0500 (CDT) 

Received: (from karn@localhost) by baaQ1075.slip.digex.net (8.7.4/8.7.3) id 
BAAOO279; Sat, 29 Jun 1996 01:25:41 -0400 (EDT) 

Date: Sat, 29 Jun 1996 01:25:41 -0400 (EDT) 

From: Phil Karn Jr <karn@baa01075.slip.digex.net> 

Message-Id: <199606290525.BAAQ0279@baa01075.slip.digex.net> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.16.19960629043259 .3667fa2c@ucs.orst.edu> (message from Johan 
Forrer on Fri, 28 Jun 1996 22:36:04 -0500 (CDT)) 

Subject: Re: [HFSIG:1246] Re: Question on orthoganal tone spacing 


Reply-To: karn@qualcomm.com 
>OK so where does this leave us with the issue of orthogonality? 
Johan, 


I'm out of town so I don't have access to my textbooks, but I *thinkx 
the issue is whether you're using coherent or noncoherent detection. 
With a coherent carrier reference at the receiver, you can use carrier 
Spacing twice as dense as with noncoherent detection. 


Since you are using DQPSK, I assume you're doing noncoherent detection. 
That could explain your need for greater tone spacing. 


Phil 


From bm@lynx.ve3jf.ampr.org Sat Jun 29 11:32:55 1996 

Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAAQ1365 for <hfsig@tapr.org>; Sat, 29 Jun 
1996 11:32:51 -0500 (CDT) 

Received: (from bm@localhost) by lynx.ve3j£.ampr.org (8.6.12/8.6.12) id QAA02843 
for hfsig@tapr.org; Sat, 29 Jun 1996 16:34:04 GMT 

From: Barry McLarnon VE3JF <bm@lynx.ve3jf£.ampr.org> 

Message-Id: <199606291634.QAA02843@lynx.ve3jf£.ampr.org> 

Subject: Re: [HFSIG:1247] Re: Question on orthoganal tone spacing 

To: hfsig@tapr.org 

Date: Sat, 29 Jun 1996 16:34:04 +0000 (GMT) 

In-Reply-To: <199606290525.BAA00279@baa01075.slip.digex.net> from "Phil Karn Jr" 
at Jun 29, 96 01:44:39 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 


> >OK so where does this leave us with the issue of orthogonality? 

> 

> Johan, 

> 

> I'm out of town so I don't have access to my textbooks, but I x*xthinkx 
> the issue is whether you're using coherent or noncoherent detection. 

> With a coherent carrier reference at the receiver, you can use carrier 
> spacing twice as dense as with noncoherent detection. 

> 

> Since you are using DQPSK, I assume you're doing noncoherent detection. 
> That could explain your need for greater tone spacing. 

> 

> Phil 


This is true, but with coherent detection you can achieve a minimum 
orthogonal carrier spacing of 1/(2T). With noncoherent detection, the 
minimum spacing is 1/T as previously stated. A good example of a 
practical system using 1/T carrier spacing and noncoherent detection 
(DQPSK) is the Eureka 147 Digital Audio Broadcast system. For Mode 2 
DAB, which we use here in Canada at L Band, the parameters are: 


Transmitted symbol length T = 312.5 us, composed of: 
Tg = 62.5 us (guard interval) 
Ts = 250 us (symbol length in the demodulator) 


Carrier spacing = 1/Ts = 4 KHz 
There are 384 carriers, producing an overall bandwidth of 1.536 MHz. 


I suspect that Johan's modem may not be performing well with 1/T carrier 
spacing because he is using windowing which destroys the orthogonality. 
Have you tried using rectangular windowing, Johan? And, of course, if 
you implement a guard time to avoid ISI, you must adjust the carrier 
spacing so that the orthogonality is maintained in the demodulator 
(spacing of 1/Ts rather than 1/T). 


Barry 
Barry McLarnon VE3IF/VA3TCP | Internet: bm@hydra.carleton.ca 
Ottawa Amateur Radio Club | AMPRnet: bm@lynx.ve3jf£.ampr.org 


Packet Working Group | Web: http: //hydra.carleton.ca 


